Ollie Lho <[EMAIL PROTECTED]> writes: > I got > > Welcome to elfboot, the open sourced starter. > January 2002, Eric Biederman. > Version 0.99999 > > 43:fill_inbuf() - ram buffer:0x00007a08 > 53:fill_inbuf() - nvram:0x00010000 block_count:0 > Found ELF candiate at offset 0 > safe_range start 0x10000 end 0x15720 > safe_range Conflicts with range 4 > which starts at 0x7724 ends at 0x47724 > Bad memory range: [0x0000000000010000, 0x0000000000005720) > Bad ELF Image > > 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > 02 00 03 00 01 00 00 00 e4 0e 01 00 34 00 00 00 > b0 90 15 00 00 00 00 00 34 00 20 00 04 00 28 00 > 0d 00 0a 00 > > > Where does the range 4 (0x7724 - 0x47724) come from ??
>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. Eric
