[Linux-Xtensa] Modifying the proto foroperatoroverloading

pradeep pradeep at anurag.drdo.in
Tue Feb 5 03:41:59 PST 2013


Marc
I am thinking to build the software again (with the modified TIE) , (as I don't have full production build license but have only software upgrade license). Will this solve the problem. 
My guess is It should, the only problem will be while creating/running the binaries on emulator/Fpga. That time It will cry for  "Processor ID does not match" (As binaries will have new core id). 

 Would like to know your feedback on that.
Regards
Pradeep


 
-- Original Message --
From: Marc Gauthier <marc at tensilica.com>
To: pradeep <pradeep at anurag.drdo.in>, Pete Delaney <piet.delaney at gmail.com>,<br>	Chris Zankel <chris at zankel.net>
Cc: "linux-xtensa at linux-xtensa.org" <linux-xtensa at linux-xtensa.org>,<br>	"Mahavir at linux-xtensa.org" <Mahavir at linux-xtensa.org>,<br>	Prasad <er.mahavir at gmail.com>, Max Filippov <jcmvbkbc at gmail.com>
Date: Mon, 4 Feb 2013 18:52:05 -0800
Subject: RE:  RE: [Linux-Xtensa] Modifying the proto for operatoroverloading

Pradeep,
>
>Modifying the behavior of the Tensilica compiler based on processor extension changes (even if only software) is beyond what I'm familiar with.  Sorry, but as far as I can tell, for lack of other suggestions, you need support
>
>Regards,
>-Marc
>
>
>
>________________________________
>From: pradeep [mailto:pradeep at anurag.drdo.in]
>Sent: Monday, February 04, 2013 05:28
>To: Marc Gauthier; Pete Delaney; Chris Zankel
>Cc: linux-xtensa at linux-xtensa.org; Mahavir at linux-xtensa.org; Prasad; Max Filippov
>Subject: Re: RE: [Linux-Xtensa] Modifying the proto for operatoroverloading
>
>Hi ,
>   I want to use it with XCC, and your guess is right, I dont have generator login or tech support at my disposal now. So I need to fix it somewhere in the software. Please suggest accordingly.
>
>Regards
>Pradeep
>
>-- Original Message --
>From: Marc Gauthier 
>To: pradeep , Pete Delaney ,
>Chris Zankel 
>Cc: "linux-xtensa at linux-xtensa.org" ,
>Mahavir at linux-xtensa.org, Prasad ,
>Max Filippov 
>Date: Fri, 1 Feb 2013 05:59:11 -0800
>Subject: RE: [Linux-Xtensa] Modifying the proto for operator overloading
>
>Pradeep,
>
>If the proto is only used for register save/restore sequences used by the kernel, it is possible to edit the overlay tarball (that is used to build tools and kernel for your core configuration) by hand. However, it's generally much easier to regenerate the core, which takes an hour or so. Your mention of operator overloading sounds like you're using this with the Tensilica compiler (XCC); such use is not so easy to update without regenerating the core (or maybe using tc). Sounds like you no longer have access? Did you ask your Tensilica support contact?
>
>-Marc
>
>
>
>________________________________
>From: linux-xtensa-bounces at linux-xtensa.org [mailto:linux-xtensa-bounces at linux-xtensa.org] On Behalf Of pradeep
>Sent: Friday, February 01, 2013 01:20
>To: Pete Delaney; Chris Zankel; Pete Delaney
>Cc: linux-xtensa at linux-xtensa.org; Mahavir Prasad; Max Filippov
>Subject: [Linux-Xtensa] Modifying the proto for operator overloading
>
>
>Hello all,
>I am stuck in a tricky situation. I have finalized my TIE and have generated my build. In the TIE I have used same operation to define 3-4 proto, and used them in operator overloading. One of this proto has some bug ( Attn: the instruction (TIE operation) it uses, is perfectly fine). Now I cant change my TIE file. So is it posssible to change the defination of this proto without needing to regnerate the Core. I want to change the proto to call some other operation than it presently calling.
>
>
>Regards
>Pradeep
>
>-- Original Message --
>From: Pete Delaney 
>To: Chris Zankel ,
>Pete Delaney 
>Cc: linux-xtensa at linux-xtensa.org, Mahavir Prasad ,
>Max Filippov 
>Date: Tue, 29 Jan 2013 20:05:31 -0800
>Subject: Re: [Linux-Xtensa] Re: [PATCH 0/3] xtensa: add MMUv3 and medium-level
>interrupts support
>
>On 01/14/2013 07:57 AM, Chris Zankel wrote:
>> Sorry, missed them. Added to for_next.
>>
>> Thanks,
>> -Chris
>> On 1/12/13 10:04 PM, Max Filippov wrote:
>>> On Sun, Jan 13, 2013 at 9:29 AM, Chris Zankel  wrote:
>>>> Hi Max,
>>>>
>>>> I have applied your patches except for the MMU v3 patch. It feels that
>>>> it needs a bit more clean-up, but I need to go through it more
>>>> thoroughly to be sure. For example, it's about MMU, but the description
>>>> only talks about GDB. The comments in general feel overwhelming.
>>>> Although, they maybe necessarily need to be. I'll get back to you on
>>>> this one.
>The folks in India found it very helpful while bringing up their V3 MMU
>to be able to single step through the initial TLB brain surgery and for
>DDD+gdb to correctly display the code, even when switching from the
>initial virtual == physical, through to the 0x4000,000 mapping, and then
>to the final 0xd000,0000 mapping.
>
>Most CPU don't even support doing the TLB re-mapping in the kernel.
>This TLB remapping sure makes it a lot easier when debugging early
>startup with JTAG.
>
>Try single stepping the early MMU initialisation with DDD+GDB and see
>for yourself if it's not worth it. This is very very early
>initialisation, having
>a clear definition of what the TLB should look like is extremely valuable,
>at least from my experience when I did it and with Mahavir last year when
>we had a bug during this early startup phase. Marc recognised the root cause
>when the TLB was out of sync a few stack frames later when initialising the
>platform code. This early environment is nasty when things go haywire.
>When bringing up a chip all kinds of hardware mistakes could cause bizarre
>problems that are difficult to diagnose. Having a guiding hand during the
>first 60 instructions of life can be god send.
>
>-piet
>
>>> Thank you, Chris.
>>>
>>> BTW, there are two more fixes in the xtensa-fixes-for-upstream branch
>>> that were posted a while ago, but somehow missed your for_next branch:
>>>
>>> c6e407d xtensa: add finit_module syscall
>>> 0fbadfb xtensa: avoid mmap cache aliasing
>>>
>>> I have rebased them on top of the for_next, could you please take them
>>> as well?
>>>
>>
>> _______________________________________________
>> linux-xtensa mailing list
>> linux-xtensa at linux-xtensa.org
>> http://lists.linux-xtensa.org/mailman/listinfo/linux-xtensa
>
>_______________________________________________
>linux-xtensa mailing list
>linux-xtensa at linux-xtensa.org
>http://lists.linux-xtensa.org/mailman/listinfo/linux-xtensa
>
>
>
>
>The contents of this Email communication are confidential to the addressee. If you
>are not the intended recipient you may not disclose or distribute this communication
>in any form should immediately contact the sender. The information, images, documents
>and views expressed in this Email are personal to the Sender and do not expressly or
>implicitly represent official positions of DRDO and no authority exists on behalf of
>DRDO to make any agreements, or other binding commitment by means of Email.
>
>_______________________________________________
>linux-xtensa mailing list
>linux-xtensa at linux-xtensa.org
>http://lists.linux-xtensa.org/mailman/listinfo/linux-xtensa
>
>
>[tps://hqr.drdo.in:4498/images/drdologo_footer1.jpg]
>
>The contents of this Email communication are confidential to the addressee. If you
>are not the intended recipient you may not disclose or distribute this communication
>in any form should immediately contact the sender. The information, images, documents
>and views expressed in this Email are personal to the Sender and do not expressly or
>implicitly represent official positions of DRDO and no authority exists on behalf of
>DRDO to make any agreements, or other binding commitment by means of Email.
>
>_______________________________________________
>linux-xtensa mailing list
>linux-xtensa at linux-xtensa.org
>http://lists.linux-xtensa.org/mailman/listinfo/linux-xtensa
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-xtensa.org/pipermail/linux-xtensa/attachments/20130205/c8bebb8e/attachment-0001.html


More information about the linux-xtensa mailing list