OSDev.org

The Place to Start for Operating System Developers
It is currently Sun May 28, 2017 8:15 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Sat Jan 30, 2010 4:21 pm 
Offline
Member
Member
User avatar

Joined: Fri Jun 13, 2008 3:21 pm
Posts: 1700
Location: Cambridge, United Kingdom
Hmm, though looking at the disassembly:
Code:
40141: 66 data16
40142: 0f 22 c0 mov %eax,%cr0


I'm going to say that it's 16-bit code. Evidenced by the stray data16. If it were disassembled as 16-bit code, that would be correct.

Which means the disassembly you've listed is wrong, as it's out of sync with the actual code


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Sat Jan 30, 2010 5:07 pm 
Offline
Member
Member

Joined: Mon Jan 14, 2008 5:53 am
Posts: 188
Location: Helsinki
Why are you looking at some disassembly when you could just check source code?


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Sat Jan 30, 2010 5:59 pm 
Offline
Member
Member
User avatar

Joined: Wed Feb 13, 2008 9:38 am
Posts: 138
Well, according to http://www.ptb.de/ntp/ntp.cgi it's 00:59 CET, that's 23:59 UTC.

http://xanclic.bplaced.net/quok.tar.bz2

PS: No, I didn't meet the requirement to load the file in RM. And I also don't know if I met the other requirements. [-o<


Last edited by XanClic on Sat Jan 30, 2010 6:07 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Sat Jan 30, 2010 6:03 pm 
Offline
Member
Member

Joined: Thu Jan 14, 2010 5:35 pm
Posts: 31
Ok, I hope this works :)

Notes:

- It loads ELF at 060h:0 them moves it to linked address and jumps to e_entry in real mode (e_entry/16):(e_entry mod 16)
- If ELF is linked at 40000h you should be able to boot up to 250k file sizes
- Automatic CHS / LBA detection: boot floppy or any partition under 2Tb
- Obviously automatic runtime detection of FAT-12 / FAT-16 file systems
- Acceptable Sector sizes are 512, 1024, 2048, 4096, and 8192 bytes
- As a bonus if you link 'MZ' executable it will load it at 60h:0 and jump to 60h:200h
This lets you have up to 626k boot file. (memory overruns are checked)

Edit: fixed bug in the initial version


Attachments:
boot_fat_technik3k.asm [16.92 KiB]
Downloaded 280 times


Last edited by technik3k on Sun Jan 31, 2010 5:56 am, edited 4 times in total.
Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Sat Jan 30, 2010 6:13 pm 
Offline
Member
Member

Joined: Sun Mar 15, 2009 9:45 pm
Posts: 40
fronty wrote:
Why are you looking at some disassembly when you could just check source code?


.. because I'm not so bsd-savvy ?? ;-)

Thanks for the pointer though... very instructive
Now, after reviewing the said source code, I can confirm that the openbsd boot ELF file (32 bit) effectively contains a litlle 16-bit bootstrap part (entry point),
that switches to pmode and gives execution to the rest of the 32-bit code.

One interesting thing I found via the pointer you gave, is the 'biosboot' source code,

http://www.openbsd.org/cgi-bin/cvsweb/s ... S?rev=1.40

whose comments show how comparable it is to the goals of this contest,
except :
-apparently the file system used is not FAT1X but rather UFS (bsd standard ??) with inodes, direct block table, etc...
-many parameters are {hard coded/patched at install} in the boot loader (inodeblk, inodedbl, fs_bsize_p, etc...) whereas in this contest, we must compute them at run time

In particular :
* We would have liked biosboot to go from the superblock to
* the root directory to the inode for /boot, thence to read
* its blocks into memory.
*
* As code and data space is quite tight in the 512-byte
* partition boot sector, we instead get installboot to pass
* us some pre-processed fields.
hehe.. :-)
If somebody ever reaches the contest's goal, we won't need any installboot or any boot sector patcher anymore...


Last edited by a427 on Mon Feb 01, 2010 3:49 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Sun Jan 31, 2010 10:51 pm 
Offline
Member
Member

Joined: Wed Oct 18, 2006 10:43 pm
Posts: 490
Location: Kansas City, KS, USA
Since I failed to mention CPU state at all in the original rules, I decided that booting in to either real mode or protected mode will be allowed. I have modified my tests accordingly. Just mention if your entry wants real mode or protected mode. I'll offer a prize for a real mode entry and a prize for a protected mode entry.


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Mon Feb 01, 2010 4:52 pm 
Offline
Member
Member

Joined: Sun Mar 15, 2009 9:45 pm
Posts: 40
@quok:

concerning the real/protected mode bootstrap mode ambiguity, perhaps it would have been wise to
expect the boot loader to start the OSLOADER in realmode *by default* (as it is the case for a legacy x86 cpu at power up), except
if this particular OSLOADER file is *multiboot* compliant ?

http://www.gnu.org/software/grub/manual ... iboot.html

=> in this case, we should boot it in 32 bit protected mode..

This way, such a designed bootloader would be :
-able to boot either of them with recompiling or run time options
-able to boot the (16 bit bootstrap) openbsd 'boot' (as advertised)
-even cooler :-)

just my .02


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Mon Feb 01, 2010 4:59 pm 
Offline
Member
Member

Joined: Wed Oct 18, 2006 10:43 pm
Posts: 490
Location: Kansas City, KS, USA
a427 wrote:
@quok:

concerning the real/protected mode bootstrap mode ambiguity, perhaps it would have been wise to
expect the boot loader to start the OSLOADER in realmode *by default* (as it is the case for a legacy x86 cpu at power up), except
if this particular OSLOADER file is *multiboot* compliant ?

http://www.gnu.org/software/grub/manual ... iboot.html

=> in this case, we should boot it in 32 bit protected mode..

This way, such a designed bootloader would be :
-able to boot either of them with recompiling or run time options
-able to boot the (16 bit bootstrap) openbsd 'boot' (as advertised)
-even cooler :-)

just my .02


Actually, my osloader is of course a 32-bit ELF file and it does expect to be started from real mode. The ELF entry point is that 16-bit code. It just sets up a protected mode environment and jumps some C code. There's also a multiboot header which utilizes the a.out kludge to specify a different entry point for multiboot-compliant loaders. This entry point just copies the loader to low memory where it expects to be, then sets up the same protected mode environment and then jumps to the same C code. For the purposes of this contest I just #ifdef out the real-mode code and change the entry point in the linker script for the protected mode version of the loader. I don't expect anyone to write a bootsector that can run both the real mode and protected mode versions except perhaps with different compile-time options.


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Tue Feb 02, 2010 4:28 pm 
Offline
Member
Member
User avatar

Joined: Wed Feb 13, 2008 9:38 am
Posts: 138
Well, since my entry didn't work on the mentioned 486 laptop, I changed it a bit and here's the new one. I hope this will work at least as well as the last did. :D

Well, this entry lacks a feature the before had: It doesn't enable the A20 line anymore. :wink:

Well, here it is: http://xanclic.bplaced.net/quok-v2.tar.bz2

Hope it works, though I don't think so. :mrgreen:


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Thu Feb 04, 2010 8:52 pm 
Offline
Member
Member

Joined: Thu Jan 14, 2010 5:35 pm
Posts: 31
This is improved version of the boot loader:

- It now can boot ELF files up to 512k in size.
- Boot 'MZ' and flat binaries up to 626k in size.
- Boot Windows 98's IO.SYS anywhere under 2Tb.
- Boot FreeDOS's kernel.sys
- User configurable boot file name (via volume label).

- Variable Sector Size (512, 1k, 2k, 4k), FAT-12 / FAT-16, and CHS/LBA are all detectable at runtime.

Please, give it a good testing on various hardware, because I have only tried it on two PCs and emulators.
If somebody has access to floppies with sector size other than 512 bytes testing will be greatly appreciated.

Thanks,
technik3k

Edit: fixed bug testing for bad cluster #


Attachments:
boot_fat_technik3k2.asm [16.31 KiB]
Downloaded 453 times
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group