On Wed, Mar 13, 2002 at 12:21:43PM -0700, Eric W. Biederman wrote:
> Kei Furuuchi <[EMAIL PROTECTED]> writes:
>
> > Hello,
> >
> > I failed to boot from etherboot as payload in linuxbios.
>
> O.k. So with etherboot you have problems booting a kernel, over
> the network.
>
> > The failing message is this:
> >
> > >> ...(ELF)... segment in reserved area
> >
> > and I checked the failing part in "osloader.c":
> >
> >
> > 1030- return 0;
> > 1031- }
> > 1032- phdr=(Elf32_Phdr *)((unsigned int)&info
> > 1033- + (unsigned int)(info.elf32.e_phoff));
> > 1034- /* Check for Etherboot related limitations. Memory
> > 1035: * below 0x10000 and between RELOC and 0xfffff is not
> > 1036- * allowed. Reasons: the Etherboot code/data area
> > 1037- * and the ROM/IO area. */
> > 1038- for (segment = 0; segment < info.elf32.e_phnum;
> > 1039- segment++) {
> > 1040- unsigned int start, end;
> > --
> > 1047- }
> > 1048-#endif
> > 1049- start = phdr[segment].p_paddr;
> > 1050- end = phdr[segment].p_paddr+phdr[segment].p_memsz;
> >
> > 1051- if ((phdr[segment].p_paddr < 0x100000) &&
> > 1052: (end > RELOC)) {
> > 1053- printf("segment in reserved area\n");
> > 1054- return 0;
> > 1055- }
> > 1056- fit = 0;
> > 1057- for(i = 0; i < meminfo.map_count; i++) {
> >
> >
> > And this I don't understand.
> >
> > RELOC is defined 0x94000 and oviously less less than 0x100000.
>
> RELOC is where etherboot lives.
> 0x100000 is 1MB. Between etherboot and the 384KB legacy dos memory
> hole there isn't really any memory left to use.
>
> > And paddr of vmlinux is 0x100000 but, applying mkelfImage makes
> > it 0x10000, which is obviosly less than 0x100000.
>
> There is a bit of code (some of it in real mode) that needs to run
> before we jump to the Linux kernel. It loads at 0x10000 to do
> some interesting things. Address 0x10000 is convinietly out of
> the way for kernel loading purposes. The etherboot comment about 0x10000
> is currently bogus.
>
Now I understand that the condition should read that something that loads
below 1MB should end before RELOC.
This means that the memory size restriction of 528kB applies like flash rom
in case of elfboot in etherboot in linuxbios?
When the kernel that I use for payload for DoC reports that :
vmlinux: file format elf32-i386
Program Header:
LOAD off 0x00001000 vaddr 0xc0100000 paddr 0xc0100000 align 2**12
filesz 0x0012ccb8 memsz 0x0012ccb8 flags rwx
LOAD off 0x0012e000 vaddr 0xc022e000 paddr 0xc022e000 align 2**12
filesz 0x0003c0e0 memsz 0x00069ea8 flags rwx
When mkelfImage is applied:
elfImage: file format elf32-i386
Program Header:
NOTE off 0x00001000 vaddr 0x00010000 paddr 0x00010000 align 2**2
filesz 0x000001c0 memsz 0x000001c0 flags r--
LOAD off 0x00001000 vaddr 0x00010000 paddr 0x00010000 align 2**12
filesz 0x00255e38 memsz 0x0025a0e0 flags rwx
Regarding memory size it is too big when loaded at 0x10000.
> > and why conditioned &&?
> > Actually how do I make elfboot image of vmlinux?
> > I assumed to use mkelfImage.
>
> Right mkelfImage should do the job.
> There are a few rough spots in loading the Linux kernel. I'm almost
> to the point of having a clean patch, but for now mkelfImage gets
> the job done.
>
> Report version numbers and the output of:
> readelf -a net-boot-image (i.e. what you are asking etherboot to load)
>
I use both 1.12 and 1.6 of mkelfImages and both seem to report identical
results like above.
Kei.
> And I'll have a clue what is going on.
>
> One possibility is that etherboot isn't finding the memory sizing
> information. And so it thinks 1MByte is beyond the end of memory...
>
> Eric
