From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by ozlabs.org (Postfix) with ESMTP id E3751DDDA9 for ; Tue, 24 Feb 2009 18:54:16 +1100 (EST) Received: by nf-out-0910.google.com with SMTP id k4so992353nfd.9 for ; Mon, 23 Feb 2009 23:54:14 -0800 (PST) MIME-Version: 1.0 Sender: sylvain.joyeau@gmail.com In-Reply-To: References: <85a5c2010902230439n1096196dr519462513bc3910d@mail.gmail.com> <85a5c2010902230648m72b63eeds70b4e7a5ec4d8c51@mail.gmail.com> Date: Tue, 24 Feb 2009 08:54:14 +0100 Message-ID: Subject: Re: Problem with decrementer interrupt From: "sjoyeau@wanadoo.fr" To: sumedh tirodkar Content-Type: multipart/alternative; boundary=0015174c10a0e65a070463a56c9e Cc: linuxppc-dev@ozlabs.org Reply-To: sjoyeau@wanadoo.fr List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --0015174c10a0e65a070463a56c9e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sumedh, I've just noticed you are using the "bla" instruction, which use absolute target address: are you sure the C code gets even be executed ? I don't know how the compiler successfully assemble your code because the binary is supposed to be position independant code (PIC): you should rather use "bl" instruction (relative branch). -- sj 2009/2/23 sumedh tirodkar > > I have initialised to stack pointer(r1) properly...actually...i went > thru the object dump...bt when i juz use > > bla > > the link register is not getting pushed on to the stack in the prolog > of that function...so the stack is basically not coming into the > picture... > @IRQ originator, that doesn't seem to be a problem... > > The only thing that i am able to think of is that when i do a "bla", > the return address is not getting stored in link register...and i m > not able to figure out why... > > Regards, > Sumedh > > On Mon, Feb 23, 2009 at 11:03 PM, sjoyeau@wanadoo.fr > wrote: > > Hi Sumedh, > > > > You may check the context in which your CPU in running the C code from > > interrupt context (ie stack pointer (r1), kernel locks disabling > > rescheduling etc..) and double check the IRQ originator (the decremente= r) > is > > acknowlegded somewhere your handler before enabling back interrupts, el= se > > your handler gets fired. > > > > -- > > sj > > > > 2009/2/23 sumedh tirodkar > >> > >> Alright...I am trying to develop a system of my own.. > >> Consider that i am not using any linux kernel...I m writing some > >> program right from scratch......... > >> The major steps that i have taken are... > >> > >> 1. Started with a assembly file... > >> 2. Have relocated the interrupt handlers to there respective > >> positions...The interrupt handlers are written in assembly language... > >> 3. Initialised Decrementer register to get an interrupt after some > >> interval... > >> 4. Jump to some function using > >> > >> bl > >> > >> function_name_main which will have a infinite while loop.. > >> This works fine i.e. the interrupts(decrementer interrupt to be more > >> specific) work fine...I have initialised serial port to get the > >> output... > >> > >> Now, the problem that i am facing.... > >> > >> If in interrupt handler of the decrementer, i make a call to some C > >> function in some other C file...using the follwing statement... > >> > >> Dec_handler: /* I have relocated this to interrupt vector address of > >> decrementer interrupt*/ > >> /*code to print using serial port*/ > >> bla /*code to call some function in C file= */ > >> /*code to print using serial port---but i m never able to see this > >> output*/ > >> RFI > >> > >> This starts creating a problem...somehow we dont return to this code > >> after the end of the function_name_handler... > >> Consider the following code for the function_name_handler: > >> void function_name_handler(void) > >> { > >> /*Some action*/ > >> } > >> > >> So, if its possible for anyone to help me with this...please reply... > >> > >> Regards, > >> Sumedh > >> > >> > >> On Mon, Feb 23, 2009 at 8:18 PM, Matt Gessner > wrote: > >> > > >> > > >> > On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar > >> > > >> > wrote: > >> >> > >> >> I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC... > >> > > >> > What I said earlier was: You need to tell people what cpu you're > using, > >> > what > >> > linux kernel, etc etc etc. > >> > > >> > Fine, we know the CPU. What kernel are you using? Is it ancient? > >> > > >> > I doubt the information below is going to be useful... > >> > > >> >> > >> >> I am using > >> >> > >> >> bla > >> >> > >> >> from the assembly code to call the function in C file...This i am > >> >> doing from interrupt handler of the decrementer... > >> >> If any more details are required, please let me know... > >> > > >> > > >> _______________________________________________ > >> Linuxppc-dev mailing list > >> Linuxppc-dev@ozlabs.org > >> https://ozlabs.org/mailman/listinfo/linuxppc-dev > > > > > > > > -- > > ------------------ > > Sylvain JOYEAU > > Freelance Engineer > > Software RT-OS R&D > > sylvain.joyeau@gmail.com > > T=E9l: +33-(0)667 477 052 > > "A good idea is one side of the coin. The other side is the practical > > usefulness". J. Liedke. > > > > > --=20 ------------------ Sylvain JOYEAU Freelance Engineer Software RT-OS R&D sylvain.joyeau@gmail.com T=E9l: +33-(0)667 477 052 "A good idea is one side of the coin. The other side is the practical usefulness". J. Liedke. --0015174c10a0e65a070463a56c9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sumedh,

I've just noticed you are using the "bla" inst= ruction, which use absolute target address: are you sure the C code gets ev= en be executed ?
I don't know how the compiler successfully assemble= your code because the binary is supposed to be position independant code (= PIC): you should rather use "bl" instruction (relative branch).
--
sj

2009/2/23 sumedh tirodkar <sumedhtirod= kar@gmail.com>

I have initialised to stack pointer(r1) properly...actually...i went
thru the object dump...bt when i juz use

=A0bla <function_name_handler>

the link register is not getting pushed on to the stack in the prolog
of that function...so the stack is basically not coming into the
picture...
@IRQ originator, that doesn't seem to be a problem...

The only thing that i am able to think of is that when i do a "bla&quo= t;,
the return address is not getting stored in link register...and i m
not able to figure out why...

Regards,
Sumedh

On Mon, Feb 23, 2009 at 11:03 PM, sjo= yeau@wanadoo.fr <sjoyeau@wanad= oo.fr> wrote:
> Hi Sumedh,
>
> You may check the context in which your CPU in running the C code from=
> interrupt context (ie stack pointer (r1), kernel locks disabling
> rescheduling etc..) and double check the IRQ originator (the decrement= er) is
> acknowlegded somewhere your handler before enabling back interrupts, e= lse
> your handler gets fired.
>
> --
> sj
>
> 2009/2/23 sumedh tirodkar <sumedhtirodkar@gmail.com>
>>
>> Alright...I am trying to develop a system of my own..
>> Consider that i am not using any linux kernel...I m writing some >> program right from scratch.........
>> The major steps that i have taken are...
>>
>> 1. Started with a assembly file...
>> 2. Have relocated the interrupt handlers to there respective
>> positions...The interrupt handlers are written in assembly languag= e...
>> 3. Initialised Decrementer register to get an interrupt after some=
>> interval...
>> 4. Jump to some function using
>>
>> =A0 =A0bl <function_name_main>
>>
>> =A0 =A0function_name_main which will have a infinite while loop..<= br> >> This works fine i.e. the interrupts(decrementer interrupt to be mo= re
>> specific) work fine...I have initialised serial port to get the >> output...
>>
>> Now, the problem that i am facing....
>>
>> If in interrupt handler of the decrementer, i make a call to some = C
>> function in some other C file...using the follwing statement... >>
>> Dec_handler: =A0/* I have relocated this to interrupt vector addre= ss of
>> decrementer interrupt*/
>> =A0 =A0 /*code to print using serial port*/
>> =A0 =A0 bla <function_name_handler> /*code to call some func= tion in C file*/
>> =A0 =A0 /*code to print using serial port---but i m never able to = see this
>> output*/
>> =A0 =A0 RFI
>>
>> This starts creating a problem...somehow we dont return to this co= de
>> after the end of the function_name_handler...
>> Consider the following code for the function_name_handler:
>> void function_name_handler(void)
>> {
>> =A0 /*Some action*/
>> }
>>
>> So, if its possible for anyone to help me with this...please reply= ...
>>
>> Regards,
>> Sumedh
>>
>>
>> On Mon, Feb 23, 2009 at 8:18 PM, Matt Gessner <mgessner@gmail.com> wrote:
>> >
>> >
>> > On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
>> > <sumedhtirodka= r@gmail.com>
>> > wrote:
>> >>
>> >> I am using PowerPC 7447A...I am trying to port SA-RTL on = PowerPC...
>> >
>> > What I said earlier was: You need to tell people what cpu you= 're using,
>> > what
>> > linux kernel, etc etc etc.
>> >
>> > Fine, we know the CPU. =A0What kernel are you using? =A0Is it= ancient?
>> >
>> > I doubt the information below is going to be useful...
>> >
>> >>
>> >> I am using
>> >>
>> >> bla <function_name>
>> >>
>> >> from the assembly code to call the function in C file...T= his i am
>> >> doing from interrupt handler of the decrementer...
>> >> If any more details are required, please let me know... >> >
>> >
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org=
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
>
> --
> ------------------
> Sylvain JOYEAU
> Freelance Engineer
> Software RT-OS R&D
> sylvain.joyeau@gmail.com
> T=E9l: +33-(0)667 477 052
> "A good idea is one side of the coin. The other side is the pract= ical
> usefulness". J. Liedke.
>





--
-----------= -------
Sylvain JOYEAU
Freelance Engineer
Software RT-OS R&Dsylvain.joyeau@gmail.com<= br> T=E9l: +33-(0)667 477 052
"A good idea is one side of the coin. The= other side is the practical usefulness". J. Liedke.
--0015174c10a0e65a070463a56c9e--