Carl-Daniel Hailfinger wrote:
On 14.11.2008 19:54, Jordan Crouse wrote:
Carl-Daniel Hailfinger wrote:
On 14.11.2008 19:06, Stefan Reinauer wrote:
ron minnich wrote:
On Fri, Nov 14, 2008 at 9:53 AM, Stefan Reinauer stepan@coresystems.de wrote:
Carl-Daniel Hailfinger wrote:
> On 14.11.2008 18:14, svn@coreboot.org wrote: > > >> Author: rminnich >> New Revision: 1026 >> >> /home/rminnich/coreboot-v3/build/coreboot.initram_partiallylinked.o: >> section .data.rel.ro.local: dual_channel_slew_group_lookup.3242 >> single_channel_slew_group_lookup.3243 >> > Basic rule: If you want to have arrays of pointers in initram, > you lose. > Pointers are not relocatable by definition. const is not going to > help > you there. > Hm. This is bad. 'nother regression in v3 that wasn't in v2.
it's not acceptable as a rule. We have to fix it one way or another. Why gcc is marking it as writeable is a puzzle but points to a bug somewhere.
We could try and use indices instead of pointers. That's the easiest rewrite i can think of to get the problem done without wasting the code.
This is clearly a gcc weakness. This stuff should not happen when compiling PIC. That's what PIC is for.
We're missing one crucial piece which is necessary to get PIC to work: The linker. PIC code must be linked _after_ its location is known. That means a linker would have to pass over the final LAR archive. Right now, we circumvent that requirement by using early linker tricks and by prohibiting the use of arrays of pointers.
If we insist on using arrays of pointers, we must either run a linker over the final LAR archive or abandon LAR completely and go for v2 linker magic.
Fully agreed. If we run a linker over the final LAR archive, then we will need a way to run the linker every single time the LAR has changed (including, mind you, on target, if we are going to go for the "replace stages on the fly" thing). Does not sound appetizing at all. I also don't like abandoning LAR - it is useful for payloads and such.
Yes, I'd like to keep LAR and I'd also like to avoid linker runs on the final LAR.
But I don't think thats what you meant - I think you meant to say that we should "abandon the stages concept".
Abandoning stages won't fix this, unfortunately. The problem is PIC in a LAR. (Okay, if we merged initram into the boot block, it would work, but that would kill the ability to have fallback/normal initram).
Yep, it sure would.
And you know what - with all due respect to Ron, I tend to be in favor of that option. Stages continue to be rather painful. Just one guy's opinion.
I found stages rather useful, but that's only my personal opinion.
There is a difference between theoretically useful and technologically feasible. As it stands, we are starting to have to make serious compromises between the code we want to write, and the design we want to keep. And even more unfortunately, we are starting to dip in to the issues that we cannot easily protect against until the linker dies with an error of questionable usefulness.
The problem is that our good intentions are revealing an ugly side - kind of like the mercury in a florescent light bulb. Everything we have been taught about embedded programming says that we need to share as much code as possible. And there is code that we want to share between stages. And we want to use standard C constructs such as pointers throughout the code. All this with the pesky constraint that we have "memory" but we don't actually have memory.
Everything we know about the coreboot design in v2 is that we want stages. And everything we know about the v2 design says that we don't like linker scripts, and we hate home grown compiler tools. We want to pull everything off with just a $(CC) call, but it is clear we are quickly exposing the limitations of the compiler.
So we are in a no-mans land. We want to share code and data between stages, but we want stages to be completely separate. And we want to do this without reinventing any wheels from POSIX and adding many K of infrastructure to the ROM to do it. Eventually, something is going to give. There will be a sacrifice. I advocate removing stages all together and instituting a single binary loader to rule them all, but I am biased since I have not yet personally had a need for a fallback kernel nor am I at all interested in updating individual stages on the fly. Certainly, the HPC folks have a dramatically different opinion - these are debates that can be held assuming the community universally agrees that a compromise is needed.
Jordan