I found out the problem...it was somewhere in my code...actually the
link register was getting over-written...
Thanks for help...
Regards,
Sumedh
On Tue, Feb 24, 2009 at 5:23 PM, sumedh tirodkar
<sumedhtirod...@gmail.com> wrote:
> The reason that i m using bla is that i am writing the interrupt
> handler from dec_start: to dec_end:....
> then i am relocating this code to its corresponding vector
> location(0x900)...As this relocated code is gonna be executed on
> occurrence of interrupt, i cant use bl instruction...i have to go for
> bla...
> The C code is getting executed for sure...hav checked this using some
> debug message...But the return from that function is not
> happening...somehow the link register is not getting properly
> loaded...dont knw wat is the reason behind this...
>
> Regards,
> Sumedh
>
> On Tue, Feb 24, 2009 at 1:24 PM, sjoy...@wanadoo.fr <sjoy...@wanadoo.fr>
> wrote:
>> 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 <sumedhtirod...@gmail.com>
>>>
>>> I have initialised to stack pointer(r1) properly...actually...i went
>>> thru the object dump...bt when i juz use
>>>
>>> bla <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",
>>> 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, sjoy...@wanadoo.fr <sjoy...@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
>>> > decrementer) is
>>> > acknowlegded somewhere your handler before enabling back interrupts,
>>> > else
>>> > your handler gets fired.
>>> >
>>> > --
>>> > sj
>>> >
>>> > 2009/2/23 sumedh tirodkar <sumedhtirod...@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 language...
>>> >> 3. Initialised Decrementer register to get an interrupt after some
>>> >> interval...
>>> >> 4. Jump to some function using
>>> >>
>>> >> bl <function_name_main>
>>> >>
>>> >> 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 <function_name_handler> /*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 <mgess...@gmail.com>
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> > On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
>>> >> > <sumedhtirod...@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. What kernel are you using? Is 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...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.joy...@gmail.com
>>> > Tél: +33-(0)667 477 052
>>> > "A good idea is one side of the coin. The other side is the practical
>>> > usefulness". J. Liedke.
>>> >
>>>
>>>
>>
>>
>>
>> --
>> ------------------
>> Sylvain JOYEAU
>> Freelance Engineer
>> Software RT-OS R&D
>> sylvain.joy...@gmail.com
>> Tél: +33-(0)667 477 052
>> "A good idea is one side of the coin. The other side is the practical
>> usefulness". J. Liedke.
>>
>
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
