"Ronald G. Minnich" rminnich@lanl.gov writes:
On 12 Feb 2003, Eric W. Biederman wrote:
Then someone modified intel_chip_post to change it's behavior when SERIAL_POST is called to output the post code to the serial port.
OK, will the guilty party please confess to me in private no need to bother the list :-)
If we want post codes to show up on the serial port even from the assembly code we need to introduce another macro, and carefully replace the users of intel_chip_post. Rather than change the calling conventions of intel_chip_post.
ok. I'll do that.
But I'm not sure it is a good idea to have a common linuxbios.a for both the compressed image and the initial image. The error was very hard for people to understand. At least this is what I think is going on, since symbols from one image were referenced from another, and the only way I could see this happening was that the 1st and 2nd stage symbols were all in the one .a
comments?
I am not certain this is happening. I guess we need to track down the multiple _start issue and see how that was triggered. In general everything in the 1st stage is included into crt0.S, so it has no need to look at linuxbios.a. So if something needs to happen it should just be a small tweak of the rules.
Ron you added a global to crt0.S and crt0.o was then linked with the 2nd stage. I guess the bug is that somehow crt0.o is being added to linuxbios.a. That looks like a leftover from before CONFIG_COMPRESS.
O.k. I have tracked the problem down. crt0.o is being manually added to OBJECTS-1 by util/config/NLBConfig.py. And OBJECTS-1 is used to populate linuxbios.a So we should be able to change one line of code and the multiple _start issue will go away.
Part of the problem was is that someone was using 1st stage defines in the 2nd stage, which is quiet unexpected. intel_chip_post is possibly the one define that is safe to use both places.
Eric