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
<[EMAIL PROTECTED]> wrote:
Carl-Daniel Hailfinger wrote:
On 14.11.2008 18:14, [EMAIL PROTECTED] 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
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
