Bootstrap loading of ELF files

[Kristof Benes]

Further to my idea last week, I've gotten it to work. I was able to
intermix 16 bit code into an ELF file using objcopy and get the ELF
unpacking routines to work on a dynamic address of the ELF image itself
(tacked onto the end of the bootstrap loader).

So what happens is thus:

The bootsector (sector 0 of the floppy) loads a file into memory
starting at 0xf000, then jumps to it. The reason I used f000 instead
what I wanted to originally 0x10000 (0x1000:0 in real mode) was the fact
that the ldgt instruction would load the wrong GDT. So then I realized
that my elf code from earlier used the Program Header Table instead of
the Section Table. The PHT works fine if all the code is in one place,
but in my case, I had some around the 0x100000 mark and some at 0x8000.
So I updated the elf section to use the section table instead of the PHT.

An objdump from the elf file looks like this:

architecture: i386, flags 0x00000002:
EXEC_P
start address 0x00100000

Program Header:
LOAD off 0x00000054 vaddr 0x00100000 paddr 0x00100000 align 2**2
filesz 0x0000000c memsz 0x00000010 flags rwx

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000005 00100000 00100000 00000054 2**2
CONTENTS, ALLOC, LOAD, CODE
1 .data 00000004 00100008 00100008 0000005c 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000004 0010000c 0010000c 00000060 2**2
ALLOC
3 .rm16 00000002 00008000 00008000 00000060 2**0
CONTENTS, ALLOC, LOAD, CODE
SYMBOL TABLE:
no symbols

I put in some dummy functions and variables to make sure that bss, data,
text and of course the new section rm16 all worked as expected, and as
of now it all seems to. However, as I work on this more and add
significant amounts of code and data to it, we'll see, but I think its
working correctly now.

In case anyone is interested, I've posted the code for the whole
bootstrap loader (should'nt be too hard to figure out where the ELF
stuff is) at http://www.maricopacomputer.com/cribix/bootstrap.asm

Hope this helps someone...

[Rod Pemberton]

"Kristof Benes" <ch...@mariremovemecopacomputer.com> wrote in message
news:0MCdnTtDDZCI5vfU...@giganews.com...

> In case anyone is interested, I've posted the code for the whole
> bootstrap loader (should'nt be too hard to figure out where the ELF
> stuff is) at http://www.maricopacomputer.com/cribix/bootstrap.asm
>

It might be of use to me modified into DOS .com ELF-loader. So, I saved it.
I noticed it didn't state copyrights or not, or Public Domain, or even your
name... If it's not copyrighted, i.e., Public Domain, it'd be nice if it
stated that. Also, it seems the code includes "gdtnasm.inc". Is that
needed? Is it easily recreatable? It'd also be nice to have a sample
"hello world" ELF file that works with it.

Rod Pemberton

[Rod Pemberton]

"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:gkqs3u$1kh$1...@news.tornevall.net...

Are you still around? While looking for "gdtnasm.inc", and finding it here:
http://www.maricopacomputer.com/OSDEV

I decided to take a look at your fat12img.tgz. I found a few bugs and some
others issues you might be interested in.

I'm not sure how you missed this one... ;-) f12rw.c has an *infinite*
loop. Yes, unless you've been hacked and someone put up their own
fat12img.tgz up on your website, it has an infinite loop. Near the end of
make83name(), the variable "i" isn't being incremented. It stays on the
same character forever:

idx++; i=0;
while (fname[idx+i] && i < 3) buf[8+i] = toupper(fname[idx+i]);
}

Add some braces and increment "i":

idx++; i=0;
while (fname[idx+i] && i < 3) { buf[8+i] = toupper(fname[idx+i]);
i++; }
}

I'd guess that because both buf[] and fname[] use "i", one of them
originally had "+i++" until someone told you that due to "sequence points"
you shouldn't do that, but that'd just be a guess as to how "i++" got
lost... In case of "sequence points," you move the "i++" out.

In makedirent(), you do this "buf[0xb]=mode;". "buf[0xb]" are the file
attributes and setting it to "mode" which is set to seven (7) was causing
the first file (only) in the floppy image to be hidden, system, and read
only (?).

f12rw.c:
make83name(buf,fname);
buf[0xb] = mode;
buf[0xc] = 0;

Set the attributes to none:

make83name(buf,fname);
buf[0xb] = 0; /* attributes, i.e., "mode" variable */
buf[0xc] = 0;

There are three fopen()'s. One in f12rw.c and two in f12main.c. I had to
make these binary mode for DOS. Without it, it was only writing the first
512 byte block of the file and zeroing the remaining blocks. This is
probably due to text mode issues. Also, text mode on DOS "converts"
characters, like 0x0a (lf) to 0x0a 0x0d (cr lf), which won't work...

f12main.c:
}
g_of = fopen(argv[1],"w");

}
g_of = fopen(argv[1],"wb");

f12main.c:
/* Read in bootsector/BPB */
f = fopen(argv[2],"r");
if (!f) {

/* Read in bootsector/BPB */
f = fopen(argv[2],"rb");
if (!f) {

f12rw.c:
}
f = fopen(filename,"r");
if (!f) {

}
f = fopen(filename,"rb");
if (!f) {

There is an unused variable "j" in f12rw.c:

int idx,i,j;

I had to change the included headers for ANSI C and/or DJGPP:

f12main.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

f12rw.c:

#include <stdio.h>
#include <ctype.h>
#include <sys/stat.h>

HTH,

Rod Pemberton