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, 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 would image Lennert went through the same thing when he created the run-time phys_offset patch. Probably need to so some research on how he did it. Regards, Steve 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 > -- > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
