OSDev.org

MessiahAndrw wrote:

quok wrote:and the second winner will be announced after community voting has closed.

What exactly will the community be looking for? The goals are very strict and there's not much room for creative freedom if at all. So if two bootsectors complete all the goals - how am I suppose to judge the better of the two?

Maybe which one is better documented ?
Or employs nifty tricks to perform the same tasks ? (code faster or smaller)
Or simply loads faster the 'osload' ELF file ?

@Quok

What about the constraints concerning the format of the resulting FAT image (with our boot loader installed via mformat),
is it supposed to be still mountable as a FAT disk ? Or is it just supposed to be booted by a machine ?

If yes, does it HAVE to be mountable by any system ?
I ask this question because Windows for instance seems to be very picky with the actual BPB content, and refuses to recognize some of my tests with
some special tricks (in custom fields not overwritten by mformat -k -B),
when linux seems to not care much apart from the main fields (geometry, etc.. all the fields that are overwritten by mformat -k -B)

What is the degree of compliance required regarding the BPB/FAT format and mountability ?

(eg: if your goal is just too first fill a valid FAT disk with your osloader, then to smash its boot sector with our entry and then only boot the resut in an emulator or a real machine; it's rather different than if you still want to mount the resulting disk, put more files on it, etc...)

Quok is out of town until Sat., but as to MessiahAndrw's question: it seems unlikely that anyone will be able to quite meet the full criteria for "winning". So the community vote is for the purpose of choosing a "winner", even if there is no winner. The community will not need to consider full compliance with all the rules -- the community will choose the "best" one, by any criteria it prefers. The community may think that a bootsector that is slightly bigger than 512b is still the best. Or one that has the niftiest code. Who knows how the mob decides in a democracy, anyway?

On your second question, you will need to wait for quok. I suspect that he would want for the bootsector/partition to mount under Windoze, too.

bewing wrote:I suspect that he would want for the bootsector/partition to mount under Windoze, too.

... otherwise it wouldn't be a valid FAT image, no?

@quok : one question regarding the OSLOADER ELF characteristics :
is it really supposed to be mapped at *ANY* address between 0-0x100000 ?
I mean for example, -Ttext=$text with :
text=0 (IVT)
text=0x7c00 (ourself)
etc...

a427 wrote:@quok : one question regarding the OSLOADER ELF characteristics :
is it really supposed to be mapped at *ANY* address between 0-0x100000 ?
I mean for example, -Ttext=$text with :
text=0 (IVT)
text=0x7c00 (ourself)
etc...

The OSLOADER ELF file will not be linked at 0x0 or 0x7c00. I'll likely have a couple of binaries linked at different addresses between 0x40000 and 0x80000. A great test, actually, would be to load OpenBSD's bootloader (known as boot(8), and installed at /boot). Just rename it to OSLOADER and place it in the root directory of your FAT filesystem. It's a statically linked ELF file, linked to run at 0x40120, and it is less than 64K in size.

MessiahAndrw wrote:The goals are very strict and there's not much room for creative freedom if at all.

That was exactly my one of my valid points ... those who remember.

MessiahAndrw wrote:So if two bootsectors complete all the goals - how am I suppose to judge the better of the two?

But only one bootsector will be posted ahead of the other. So one $50 winner.


I sincerely hope that I did not violate any rules while making this post.

geppyfx wrote:

MessiahAndrw wrote:The goals are very strict and there's not much room for creative freedom if at all.

That was exactly my one of my valid points ... those who remember.

Lots of contests strict goals and aren't necessarily about creative freedom. I suppose this is one of them. It's more about the challenge and having fun tackling that challenge, IMO.

geppyfx wrote:

MessiahAndrw wrote:So if two bootsectors complete all the goals - how am I suppose to judge the better of the two?

But only one bootsector will be posted ahead of the other. So one $50 winner.

Yes, one $50 winner, but I think MessiahAndrw's quote was taken out of context here. Wasn't he asking how to judge the better of the two bootsectors during the community vote portion of the contest? That really comes down to personal preference. Personally I'd vote for whichever bootsector has what I feel to be the better code, better documentation, etc.

quok wrote:

a427 wrote:A great test, actually, would be to load OpenBSD's bootloader (known as boot(8), and installed at /boot).

Do you have a sample of that file or know where to find one?

~ wrote:Do you have a sample of that file or know where to find one?

OpenBSD?

You can either take a copy from an existing installation, or grab baseXX.tgz from a mirror and extract it.

@quok

It's strange, now that I have something that boots 32 bit pmode ELF from FAT12, I did some experiments with the 'boot' file from openbsd,
and I wonder if this particular ELF file is not supposed to be specially bootstrapped in 16 bit real mode, plus with some special magic in registers :

Entry point address: 0x40120

boot: file format elf32-i386

Disassembly of section .text:

00040120 <.text>:
40120: 66 58 pop %ax
40122: 66 3d 0d d0 cmp $0xd00d,%ax
40126: 01 c0 add %eax,%eax
40128: 74 00 je 0x4012a
4012a: 66 5a pop %dx
4012c: fa cli
4012d: 66 0e pushw %cs
4012f: 66 1f popw %ds
40131: 67 66 0f 01 15 addr16 lgdtw (%di)
40136: 30 3f xor %bh,(%edi)
40138: 00 00 add %al,(%eax)
4013a: 0f 20 c0 mov %cr0,%eax
4013d: 66 83 c8 01 or $0x1,%ax
40141: 66 data16
40142: 0f 22 c0 mov %eax,%cr0
40145: 66 ea 4d 01 04 00 ljmpw $0x4,$0x14d
4014b: 08 00 or %al,(%eax)
4014d: b8 10 00 00 00 mov $0x10,%eax
40152: 8e d8 mov %eax,%ds

=> apparently, there are quite some extra 0x66 prefix to forge 16-bit assembly, plus we appear to load gdt and switch to protected mode...

So if one of your rules is to switch to protected mode within the loader (before bootstrapping OSLOADER), then it will prevent booting eg: the openbsd bootloader ?

a427 wrote:@quok

It's strange, now that I have something that boots 32 bit pmode ELF from FAT12, I did some experiments with the 'boot' file from openbsd,
and I wonder if this particular ELF file is not supposed to be specially bootstrapped in 16 bit real mode, plus with some special magic in registers :
<snip>
So if one of your rules is to switch to protected mode within the loader (before bootstrapping OSLOADER), then it will prevent booting eg: the openbsd bootloader ?

Ah, thanks for pointing that out, I completely forgot to mention that in your bootsector you shouldn't worry about switching to pmode. The OSLOADER, like the OpenBSD bootloader, is a 32-bit ELF file but it meant to be launched from 16 bit real mode. The first thing the osloader does (and OpenBSD's /boot) is jump to protected mode.

I'm sorry I failed to point this out earlier. Hopefully it'll make the contest a bit easier and more appealing for some people.

The 66h prefixes indicate clearly that it's 32-bit code. Of course it's loading it's own GDT; it doesn't want to rely on one which may potentially soon disappear

Owen wrote:The 66h prefixes indicate clearly that it's 32-bit code. Of course it's loading it's own GDT; it doesn't want to rely on one which may potentially soon disappear

Ok I see, in fact those prefixes are indeed necessary to execute 16 bit instructions in 32 bit-mode right ?
Thus I was wrong saying the 'boo' file must be started in 16-bit mode ? I'm confused here...

But then, as you can see in the disassembly above, how can we explain that the GDT loading happens on %di without setting it to a known value ?

40131: 67 66 0f 01 15 addr16 lgdtw (%di)

=> the openbsd 'boot' ELF file seems to expect some known values in registers (di=GDT, and we pop ax and compare it to 0xd00d ??)

quok wrote: Ah, thanks for pointing that out, I completely forgot to mention that in your bootsector you shouldn't worry about switching to pmode. The OSLOADER, like the OpenBSD bootloader, is a 32-bit ELF file but it meant to be launched from 16 bit real mode. The first thing the osloader does (and OpenBSD's /boot) is jump to protected mode.

I'm sorry I failed to point this out earlier. Hopefully it'll make the contest a bit easier and more appealing for some people.

My fault quok, in fact in your 'goals', you never explicitly mentioned booting in pmode, actually...

"Be able to load and execute a 32-bit ELF file of any size that is also linked above the first megabyte."

sorry..

But I still fail to understand how the 'boot' from opensbd is able to switch to pmode correctly without setting its %di before loading GDT at [di]....