Eric W. Biederman wrote:
>
>>From linuxBIOS. Look at the top of elfboot.c Range 4 is our heap.
> Basically we don't allow linuxBIOS to be overwritten.
>
> This is probably the biggest remaining problem with the current elfboot
> code. It conflicts to easily with random programs.
>
> The quick fix is to set rambase to something high like 0x16MB.
>
> I suspect the long term solution is to find a way to put our heap way
> at the top of memory, but memory sizing and pci_init currently
> interact at present so we can't delay the allocation of a heap until
> later. I think if I adopt the concept of an early stack, and an early
> heap that I pretty much throw away. I could implement this without
> to many code changes...
>
> An alternative that I'm busily avoiding is do what I do in my kexec
> patch and allocate buffers that I will relocate after the image has
> been completely loaded. If we do that we loose simplicity and the
> ability to return to linuxBIOS.
>
Frankly speaking, I really don't get it why you have to change the ELF
boot interface. We (other people than you) are just getting used to
use ELF boot. IMHO, the 1.6 interface is good for most application.
BTW, does mkelfImage works for any (statically linked) ELF file,
not only Linux kernel ?? Is it correct that in order to be loaded
by ELF boot, one has to
1. Use the ube_start.S instead of the usual crt0.S used by gcc.
2. Use gcc's crt0.S and convert with mkelfImage.
And what does the convert_params.c do for ELF that is not Linux
kernel ??
Ollie
