OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 24, 2017 3:56 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
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 275 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 451 times
Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Fri Mar 17, 2017 12:51 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 177
okay sorry for being 7 years late.

i am actually plan to use this new simple ,,standard'' of boot loader being introduced here. So i am actually plan to use it blindly as an user.

i plan to create a bootable stand-alone emulator for my operating system. i actually expected others to do a bootable emulator, but in the case of nobody does one, i have to do it myself. i will not do x86 assembly to do it, becouse i pretty much forgot all of my x86-related knowledges in the last 3 year, well, not all knowledge, and that makes bothering questions about the viablity of this concepcion.

however, i seen a few downloadable contest entries, from the comments i assume they work, i not yet tested them. lets put up they are working. technik3k-s solution is for example still available.

now ELF files.

as somebody also mentioned, for ELF files compiled under linux for example, needs relocations and/or protected mode with address translation, and in this case 32 bit with march=i386.

now my question is
-how this boot sequence will supply an environment where a complicated structure - like an half mbyte sized, or 200 kbyte elf file - will live in this environment
-what compilation methods and commands should i use in the compiler itself beyond the fact is specify that it should link no gnu related stuff and no st libs
-what memory address space will i have to access the actual RAM, or should the first thing i do is entering protected mode manually, and setting up address translation? i actually need 2 gbyte of RAM, a few k will not be enough.
-i dont want to do a whole kernel for this, i only want the emulator to spin my OS, but it needs SVGA and disk access for example, which is pretty much the simplest to do with oldscool interrupt calls. now if this is in protected mode, it will not work without creating v86 task support, which is totally makes this thing to just simply rot.
-or is this not for me, and should i use a different boot loader wih an unreal mode compiler?


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Wed Mar 22, 2017 4:17 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7740
Location: At his keyboard!
Hi,

Geri wrote:
now my question is
-how this boot sequence will supply an environment where a complicated structure - like an half mbyte sized, or 200 kbyte elf file - will live in this environment


It won't supply an full environment; it's just a tiny boot loader designed to be tiny (and not designed to do anything well or provide any useful features).

Geri wrote:
-what compilation methods and commands should i use in the compiler itself beyond the fact is specify that it should link no gnu related stuff and no st libs
-what memory address space will i have to access the actual RAM, or should the first thing i do is entering protected mode manually, and setting up address translation? i actually need 2 gbyte of RAM, a few k will not be enough.


You'll need to write your own "startup code" (most likely in assembly) to get a memory map, setup a video mode, switch to protected mode, etc. The boot loader does none of this; it's just a tiny boot loader designed to be tiny (and not designed to do anything well or provide any useful features).

Geri wrote:
-i dont want to do a whole kernel for this, i only want the emulator to spin my OS, but it needs SVGA and disk access for example, which is pretty much the simplest to do with oldscool interrupt calls. now if this is in protected mode, it will not work without creating v86 task support, which is totally makes this thing to just simply rot.


That sounds like you need a whole extremely badly designed kernel (e.g. with synchronous file IO, antiquated "raw pixel only" graphics driver API, etc).

Geri wrote:
-or is this not for me, and should i use a different boot loader wih an unreal mode compiler?


It would suit you perfectly - a deliberately crippled boot loader for a deliberately crippled "application pretending to be an OS" that runs on top of a deliberately crippled kernel.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Wed Mar 22, 2017 11:10 am 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 177
Brendan wrote:
It would suit you perfectly - a deliberately crippled boot loader for a deliberately crippled "application pretending to be an OS" that runs on top of a deliberately crippled kernel.


perfect. i meditated on it, and i decided to use smallerc that can supply binaries designed to run in unreal mode, so i can do svga and disk access easily.

however, i am not yet sure with the boot loader, maybe i will have to modify one, becouse i dont need x86-styte partition tables at all.


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Wed Mar 22, 2017 10:52 pm 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 177
very broken loaders. i compiled the vesa tutorial with smallerc in unreal mode, and tried bootprog with fat16 to load it. nothing happens. i tryed the contest entry posted by technik3k, qemu throw fatal: Trying to execute code outside RAM or ROM at 0x00000000000a0000. either i am idiot and forgot something, or both of the loaders are failing, or smallerc produces broken binary, or the vesa tutorial is wrong (or all of the above). i would assume that these things are not really tested together at all.


Top
 Profile  
 
 Post subject: Re: The NEW 512 Byte Contest -- Quok Style
PostPosted: Thu Mar 23, 2017 3:11 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 736
Geri wrote:
very broken loaders. i compiled the vesa tutorial with smallerc in unreal mode, and tried bootprog with fat16 to load it. nothing happens. i tryed the contest entry posted by technik3k, qemu throw fatal: Trying to execute code outside RAM or ROM at 0x00000000000a0000. either i am idiot and forgot something, or both of the loaders are failing, or smallerc produces broken binary, or the vesa tutorial is wrong (or all of the above). i would assume that these things are not really tested together at all.


Can you get demo1.com to boot with BootProg? If you can't, your FAT16 file system must be broken (boot16.asm is not for MBR, it's for an active primary DOS partition; boot16.asm must have its BPB properly initialized, the default values are mostly zeroes).

Try something simpler first. Get demo1.com working with flp144.asm and mkimg144.c.

Also, if you're using vesalfb.c from Smaller C, it won't work as a bare hardware application. It has bits of code that require DOS: __start__() (that calls DOS-dependent __DosGetVect(), __DosSetVect(), setargs() before calling main()), exit(), puts(), printf(), getchar().

You may include a watered down version of __start__() in your program in order to reach main():

Code:
void __start__(void)
{
  clock();
  __x87init();
  main(0, 0);
  for(;;);
}


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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