[Linux-Xtensa] Modifying the proto for operator overloading

[pradeep]

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 <piet.delaney at gmail.com>

				To: Chris Zankel <chris at zankel.net>,

				Pete Delaney <piet.delaney at gmail.com>

				Cc: linux-xtensa at linux-xtensa.org, Mahavir Prasad <er.mahavir at gmail.com>,

				Max Filippov <jcmvbkbc at gmail.com>

				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 <chris at zankel.net> 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
		
	




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-xtensa.org/pipermail/linux-xtensa/attachments/20130201/1fe744d4/attachment.html