On Thu, Feb 05, 2009 at 06:34:06AM -0600, Steve Chen wrote: > On Wed, 2009-02-04 at 20:57 -0700, Mark A. Greer wrote: > > On Fri, Jan 23, 2009 at 11:45:42PM +0300, Sergei Shtylyov wrote: > > > Mark A. Greer wrote: > > > > >>> With the static data being turning into dynamic, what's the win of > > >>> converting to __initdata? > > > > > > The thing that really worries me about cp_intc is entry-macro.S. > > > > Me too unless we do some GOT magic/runtime relocation and switch in new > > code for the old. :( > > > > Mark > > -- > > I can think of 2 ways to handle different interrupt handler in > entry-macro.S > > 1. cp_intc has an ID register. We can read it and handle interrupts > accordingly. > > 2. Use a variable (similar to how Lennert used phys_offset in the > run-time phys_offset patch) to determine which code to execute. Of > course this variable is set during init,
Yes, both of those are possible ways, but the point is that we don't want to introduce that code in the time-critical interrupt path. This code executes on every interrupt. It'll roughly double the amount of code in debug-macro.S, although, I admit that the extra instructions are not _that_ significant WRT the total number of instructions in the entire intr handling path. > With all these updates, it would give us a zImage that works for dmxxx > and omap-l137. However, we still need a uimage that works for dmxxx and > omap-l137. I can think of 2 ways to do this. Unfortunately, both ways > has sever drawbacks. > > 1. Modify the bootm command in u-boot to allow dynamic address/entry > point. Unfortunately, the section of code to process uImage header is > common for all architecture (ARM, PPC, x86.. everyone). Not sure if any > code we modified will ever be allowed. > > 2. Create a script/short program to modify the load address, entry > point, and recalculate header checksum. I won't list the reasons I > dislike this because it would take too long. I think what you're alluding too is the Makefile.boot issue. That issue isn't resolved and I'm not sure how it can be resolved. Neither of your options above are reasonable, IMHO. My doubts of being able to merge da830 and davinci support into one kernel binary in a reasonable way with a reasonable amount of effort continue to grow... Mark -- _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
