"Mark A. Greer" <mgr...@mvista.com> writes: > 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.
IMHO, these extra instructions are not too much overhead for debug/development kernels. What I have proposed before is that the "heavy" version (with the extra runtime checks) is used by default when multiple devices are supported, but an optimized version could be used if only a single device is built in. The other option which we use for various functions in OMAP is to have these macros just be a bunch of nops, and they can be filled out at runtime. >> 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... As far as I'm concerned, this PHYS_OFFSET isse is the only real obstacle at the moment. And for me, solving this issue is not the highest priority, since I don't care if the zImage/uImage has to be different for the time being. I'll take an #ifdef in Makefile.boot for now. I don't want these relatively small issues to be obstacles to getting the rest of the code out. I would much rather see patches for the rest of the da8xx device support coming first. Then we'll worry about the PHYS_OFFSET down the road. Kevin _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
