theosproject-developers Mailing List for The OS Project
Status: Planning
Brought to you by:
shounin
Menu
▾
▴
theosproject-developers — Questions, Comments, & Help from the Developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(67) |
Mar
(17) |
Apr
(9) |
May
|
Jun
(2) |
Jul
(8) |
Aug
(27) |
Sep
|
Oct
(4) |
Nov
(2) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(12) |
Aug
(7) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: <the...@li...> - 2005-09-25 21:25:10
|
Is anyone on this list & paying attention to it? Is anyone still interested? If so, please let me know. I'd like to either (a) try to get things going again if people are interested, or (b) remove it from sf.net to work on at home. Thanks, Ben |
|
From: <the...@li...> - 2004-06-27 02:58:02
|
I picked up the book "MMURTL V1.0" today through a
special order with Border's Books and started going
through it. While I'm still investigating the book, I
would probably recommend it for those new on the list.
Be warned, however, that the book is hard to come by,
and costs $49.95, and also that the book is a good
chunk source code. I'll give an update on it later on
after I have gone through it a lot more as to its full
value.
I'm hoping to gleam some ideas about writing the Boot
Loader, Initial Program Loader, and initial kernel
from it.
Long story short, I decided to post a small list of
requirements for the benefit of all who still care.
Boot Loader Requirements
------------------------
1. Two stage Boot Loader made up of (a) bootsector and
(b) Initial Program Loader.
2. The Boot Loader
2.1. Loaded by BIOS on start-up
2.2. Detects media loaded from (hdd/fdd)
2.3. Loads Initial Program Loader from disk
2.4. Runs in x86 Real Mode
2.5. Must be no larger than 510 bytes.
2.6. Terminates with 0xAA55 (0x55AA, depending on
BIOS)
3. Initial Program Loader
3.1. Starts in x86 Real Mode
3.2. Loads Kernel from disk
3.3. Stored on disk immediately after the boot
sector
3.4. Finds information that is 'hard' to get at
from
Protected Mode and stores it at a given
memory
location using a specified structure.
3.5. Detects whether Kernel wants 32-bit Protected
Mode (IA32) or 64-bit Long Mode (AMD64/IA32e)
3.6. Moves the processor into the mode detected by
3.4
3.7. Starts the kernel
3.8. First byte of image contains the size of the
image
in sectors for use by the Boot Loader
3.9. Detects media format of disk loaded from
3.10. Supports ext2/3 and FAT12/16/32/VFAT
filesystems
4. Storage
4.1. Boot Loader is stored in the boot sector of
the media
4.2. Initial Program Loader is stored immediately
after
the boot sector
4.3. For initial development purposes, Kernel is
stored
immediately after the Initial Program Loader
on disk
4.4. Kernel is stored on a file under a known File
System
5. Hardware
5.1. Runs on Intel x86 32-bit Protected Mode
Platform
5.2. Runs on an Intel i386 and later x86 processors
5.3. Runs on AMD64 64-bit Long Mode Platform
5.4. Runs on Intel IA32e (IA32 Extended) 64-bit
Platform
6. Programming Language
6.1. Intel x86 Assembly
6.2. C using the C89/90/99 standards
7. Software Development Environment
7.1. NASM Assembler
7.2. C Preprocessor using the GCC compiler for the
preprocessor
7.3. GCC 64/32-bit C Compiler for 64/32-bit C code
7.4. BCC 16-bit C Compiler for 16-bit C code
7.5. GNU ld for 64/32-bit linker for 64/32-bit C
code
7.6. binutil's ld86 for 16-bit linker for
7.7. NASM for linking Assembly Code
7.8. GNU Make for compilation
7.9. GNU AutoConf for source code & Makefile
configuration
7.10. GNU AutoMake for Makefile generation
Comments/feedback is welcome and would be highly
appreciated.
Requirements for other systems will come after the
boot loader has been created and loads a dummy kernel.
Goal for first release of the boot loader code is to
have the following finished:
1, 2, 3.[1-4,6-9],4.[1-3], 5.[1-2], 6, 7
I.e. 64-bit Long Mode and IA32e are not targetted yet
even though they are listed in the requirements.
Ben Meyer
Project Administrator
"You don't know the components!"
"It's American, it's russian. It's all made in
Taiwan." - Russian Cosmonaught,Armagedon movie
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
|
|
From: <the...@li...> - 2004-06-26 16:13:47
|
I've noticed that I've been the only one posting to the list. Is there anyone else that is still interested in the project? Ben "You don't know the components!" "It's American, it's russian. It's all made in Taiwan." - Russian Cosmonaught,Armagedon movie __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail |
|
From: <the...@li...> - 2004-04-23 21:52:35
|
Hi all! Currently there is a boot loader in CVS. However, while all the code is there it is not, at this time, fully compilable since the Makefile needs to be updated. So... 1) Is anyone else willing to get the current code in CVS to the point where it can compile? 2) I have another little project that involves creating a boot loader. The loader has a couple stages to go - namely, it needs to recognize difference between floppy and hard drive. This too is a two stage loader, and it is mostly Real Mode Assembly. Is anyone interested in helping out on this one? If #1 has not been accomplished by the time #2 is done; then I will probably be updating CVS to remove the current code and put in the boot sector from #2. Please notify me (preferably through this list) if you are interested in either of the above. Thank you! Benjamen R. Meyer Project Manager |
|
From: <the...@li...> - 2004-03-23 01:21:59
|
Sorry about the double post...I just wanted to add that if there is enough interest then I may take it to SF earlier than planned. Thanks! Ben Hey all! I'm working on a project for a program to read the Ralph-Brown-Interrupt-List files. The project is mainly for Linux as it comes with several Windows versions. However, if you are interested in either working on any of the following: 1) a Windows interface, 2) helping with the categoration and sort parts of the data structures, 3) helping on the Linux Console/X-Windows interface Then please let me know. I'm currently planning on taking it to SF when I have a basic, rudamentary interface for Linux using the NCurses package - at least until something better is proposed or found. All code is in C/C++. At present, the program can load the files into memory; searching & sorting routines still need to be developed. My current task is simply getting an interface to it. Any how...please let me know if you are interested in any of the above. Thank you! Benjamen R. Meyer |
|
From: <the...@li...> - 2004-03-23 01:19:52
|
Hey all! I'm working on a project for a program to read the Ralph-Brown-Interrupt-List files. The project is mainly for Linux as it comes with several Windows versions. However, if you are interested in either working on any of the following: 1) a Windows interface, 2) helping with the categoration and sort parts of the data structures, 3) helping on the Linux Console/X-Windows interface Then please let me know. I'm currently planning on taking it to SF when I have a basic, rudamentary interface for Linux using the NCurses package - at least until something better is proposed or found. All code is in C/C++. At present, the program can load the files into memory; searching & sorting routines still need to be developed. My current task is simply getting an interface to it. Any how...please let me know if you are interested in any of the above. Thank you! Benjamen R. Meyer |
|
From: <the...@li...> - 2003-10-08 01:55:09
|
Hello all! I just wanted to let you know that I've updated the website. It's quite a drastic improvement over the previous single-page fowarding site to direct people to the SF site. Any how, let the webdev list know what you think! Benjamen R. Meyer The OS Project Team Manager __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com |
|
From: <the...@li...> - 2003-09-04 11:43:28
|
Hi, is the makefile now working properly? I checked the log for the makefile and it doesn't seem that any changes have been made. Cheers, Mark Horner Physics Department University of Cape Town Rondebosch 7700 South Africa Phone: +27 21 650 3366 (office) Phone: +27 83 564 6272 (cellular) Fax: +27 21 650 3342 Homepage: http://hep.phy.uct.ac.za/~horner Co-author: http://savannah.gnu.org/projects/fhsst "It went well. There are no problems, and, as a bonus, it showed that I have a brain!" - Stormers and Springbok backrower CORNE KRIGE speaking after undergoing a precautionary brain scan after a clash of heads during a Super 12 match. On Wed, 27 Aug 2003 the...@li... wrote: > I downloaded a recent bzip'd tarball of the CVS system from the SF site. I > noticed that code has been added, but the Makefile has not been updated. We > also have some antiquity code (e.g. boot.asm, and setup.asm) leftover from > before Ian came in. > > Ian - could you please update the Makefile for the new code? > > Mark - once we have the Makefile updated, and are able to completely compile > using: > make > make install_floppy > Could you then issue a removal of the following files from the HEAD branch, > leaving them in under a prior release (say TOSP_KARTH): > boot.asm > kernel.asm > setup.asm > > > Once this is done, I'll update the ChangeLog, ToDo.txt, File_List.txt files. > > Ben > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Theosproject-developers mailing list > The...@li... > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > |
|
From: <the...@li...> - 2003-09-04 11:02:48
|
Hi all, I have added, as requested, email notifications to the CVS repository. Email notifications will be sent to this list when changes are commited to the repository. Depending on traffic and requests the information in the email can be modified easily enough. Cheers, Mark Horner Physics Department University of Cape Town Rondebosch 7700 South Africa Phone: +27 21 650 3366 (office) Phone: +27 83 564 6272 (cellular) Fax: +27 21 650 3342 Homepage: http://hep.phy.uct.ac.za/~horner Co-author: http://savannah.gnu.org/projects/fhsst "It went well. There are no problems, and, as a bonus, it showed that I have a brain!" - Stormers and Springbok backrower CORNE KRIGE speaking after undergoing a precautionary brain scan after a clash of heads during a Super 12 match. |
|
From: <the...@li...> - 2003-08-30 06:01:21
|
Just to let you guys know, NASM 0.98.37 has been released. See http://nasm.sf.net/ for details. Ben -----Original Message----- From: nas...@li... [mailto:nas...@li...] On Behalf Of H. Peter Anvin Sent: Friday, August 29, 2003 5:22 PM To: NASM development list Subject: [Nasm-devel] NASM 0.98.37 released Okay all, I have released 0.98.37... so far only source and Linux binaries. -hpa ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nasm-devel mailing list Nas...@li... https://lists.sourceforge.net/lists/listinfo/nasm-devel |
|
From: <the...@li...> - 2003-08-27 06:51:37
|
I was looking at the settings for the lists, and noticed that SF has recently re-enabled an option that sets the 'reply-to' field to the list. Personally, this would be my preference, and I would have set it up this way to begin with if it was available at the time. So, before I do make a change, I'd like to get peoples opinions. Here's the changes I'm proposing: The...@li... -> Reply-To unmodified The...@li... -> Reply-To changed to list The...@li... -> Reply-To changed to list I'd like to collect all votes by the end of the month (August) - e.g. next Monday. Your opinions are much appreciated! Thank you! Benjamen R. Meyer The OS Project List Administrator |
|
From: <the...@li...> - 2003-08-27 06:49:24
|
I downloaded a recent bzip'd tarball of the CVS system from the SF site. I noticed that code has been added, but the Makefile has not been updated. We also have some antiquity code (e.g. boot.asm, and setup.asm) leftover from before Ian came in. Ian - could you please update the Makefile for the new code? Mark - once we have the Makefile updated, and are able to completely compile using: make make install_floppy Could you then issue a removal of the following files from the HEAD branch, leaving them in under a prior release (say TOSP_KARTH): boot.asm kernel.asm setup.asm Once this is done, I'll update the ChangeLog, ToDo.txt, File_List.txt files. Ben |
|
From: <the...@li...> - 2003-08-12 17:38:16
|
An omission from yesterdays email: If you try to connect with wincvs and you get messages about the key not being in the cache then use plink to connect to the server on its own and store the key in your cache - wincvs doesn't seem to be able to handle the query from plink. using TortoiseCVS is simpler than WinCVS. It also has better documentation. To install TortoiseCVS download it from : http://www.tortoisecvs.org/download.shtml Then run the installer - it is small and a lot of the files you don't need so do a custom install and leave out the languages, unless of course you want one of them. The majority of the files are different icon sets or different languages. Install at least the icon set by Mathias Hasselman. I strongly recommend changing the icon set to one of the other sets, the default icons make next to no sense. Once this is done, with the customary reboot, TortoiseCVS interfaces nicely with Explorer so right clicking on a folder will present a menu now containing TortoiseCVS options. My pick is the set by Mathias Hasselman - these are clean and intuitive. This can be done by right clicking on a folder in explorer -> CVS -> Preferences -> and changing Icon Overlays. Then you MUST generate keys if you haven't already and place then on the respective servers as in the previous email. Then with pageant running and your private key file loaded you can use tortoisecvs to access the various servers: Now if you have waited long enough for the keys to propagate in the cases of savannah and sourceforge you can access CVS. To checkout a module right click on the folder you want to store it in. Click on CVS checkout on the menu. Remember you must have pageant running and you must have added your private key for authentication to work. type in the CVSROOT that applies: Savannah: CVSROOT: :ext:<your_username>@subversions.gnu.org:/cvsroot/fhsst Sourceforge: CVSROOT: :ext:<your_username>@cvs.sourceforge.net:/cvsroot/theosproject HEP: CVSROOT: :ext:<your_username>@hep.phy.uct.ac.za:/home/cvsadmin/cvs Then at the bottom type in the module name: Savannah: fhsst Sourceforge: winux Hep: take your pick. Thats the basic checkout - there is documentation for the rest - and you can do commits etc. by right-clicking on the file in the list to get a menu of options. Cheers, Mark Mark Horner Physics Department University of Cape Town Rondebosch 7700 South Africa Phone: +27 21 650 3366 (office) Phone: +27 83 564 6272 (cellular) Fax: +27 21 650 3342 Homepage: http://hep.phy.uct.ac.za/~horner Co-author: http://savannah.gnu.org/projects/fhsst "It went well. There are no problems, and, as a bonus, it showed that I have a brain!" - Stormers and Springbok backrower CORNE KRIGE speaking after undergoing a precautionary brain scan after a clash of heads during a Super 12 match. |
|
From: <the...@li...> - 2003-08-11 18:39:03
|
this is not, by far, the only way to use CVS under windows but its easy and free. download from: http://www.putty.nl/download.html puttygen plink pageant download from: http://sourceforge.net/projects/cvsgui wincvs 1.3+ and install it. Key Generation: use puttygen to generate a key of type rsa1 or 2 depending on any specific requirements your server may have savannah.gnu.org : rsa1 sourceforge.net : rsa1 or 2 hep.phy.uct.ac.za : rsa1 or 2 then you save the key public and private keys in a folder of your choice - remember your key phrase that goes with the private key. Savannah users: register your public key on your account configuration page and wait at least an hour before attempting to access CVS. Sourceforge users: register your public key on your account configuration page and wait up to 6 hours before accessing CVS will be successful. Hep users: plink into hep (just like normal ssh) and enter the directory .ssh here either append your public key to the file "authorized_keys" or create this file with your only your pbulic key in it. Once you have generated and saved your keys you can run pageant to manage the keys. Pageant will run in the toolbar - click on the icon and Add Key - then load your private key file. It will prompt for your pass phrase. Make sure this is running when you run wincvs. Then you can run wincvs. To configure wincvs: Savannah: Click on Admin Click on Preferences Set the following: Authentication type: ssh CVSROOT: :ext:<your_username>@subversions.gnu.org:/cvsroot/fhsst Click on Authentication Settings Set the following: ssh client: <path>\plink.exe Additional ssh options: -ssh Sourceforge: Click on Admin Click on Preferences Set the following: Authentication type: ssh CVSROOT: :ext:<your_username>@cvs.sourceforge.net:/cvsroot/theosproject Click on Authentication Settings Set the following: ssh client: <path>\plink.exe Additional ssh options: -ssh HEP: Click on Admin Click on Preferences Set the following: Authentication type: ssh CVSROOT: :ext:<your_username>@hep.phy.uct.ac.za:/home/cvsadmin/cvs Click on Authentication Settings Set the following: ssh client: <path>\plink.exe Additional ssh options: -ssh Now if you have waited long enough for the keys to propagate in the cases of savannah and sourceforge you can access CVS. You need to choose a working directory in wincvs. To checkout a module to a folder click on Remote -> checkout module then fill in the following: Savannah: Module name: fhsst Sourceforge: winux Hep: take your pick. Then fill in the folder you want to make the module directory in and go for it. Thats the basic checkout - there is documentation for the rest - and you can do commits etc. by right-clicking on the file in the list to get a menu of options. I ahven't setup TortoiseCVS but it works directly with Explorer. Looks quite simple as well. Cheers, Mark Mark Horner Physics Department University of Cape Town Rondebosch 7700 South Africa Phone: +27 21 650 3366 (office) Phone: +27 83 564 6272 (cellular) Fax: +27 21 650 3342 Homepage: http://hep.phy.uct.ac.za/~horner Co-author: http://savannah.gnu.org/projects/fhsst "It went well. There are no problems, and, as a bonus, it showed that I have a brain!" - Stormers and Springbok backrower CORNE KRIGE speaking after undergoing a precautionary brain scan after a clash of heads during a Super 12 match. |
|
From: <the...@li...> - 2003-08-02 07:11:02
|
Oh, and one more thing. Could you please provide a Makefile that will compile all of it? (Or a Makefile.in so we can go straight to autoconf.) Much appreciated! Thanks! Ben > -----Original Message----- > From: the...@li... > [mailto:the...@li...] > Sent: Friday, August 01, 2003 3:33 AM > To: the...@li... > Subject: RE: [TOSP_Developers] Boot Compression & Checksumming > > > Cool! Sorry for my lack of e-mails here - I've been unable to connect for > the last couple days. Alls good now. > > On the 4MB RAM: > > How about we make this a compile option? (It could be added later if we > wanted to skip it now, if it was too much to do.) > > On the Checksum: > > That actually sounds great, and would give us the ability to do even a > simple security check. I would put a compile option to disable > it and leave > it in as default, at least when we get a lot closer to the 1.0 release, > though it might be neat to see it go through until then too. > > Thanks! > > Ben > > > I have nearly completed a decompressor based upon the > > bzip2 utility source code. The problem is not the size > > of the decompression code but the 2.7Mb of memory that > > the decompressor uses. If we plan on supporting 4Mb > > memory platforms this could be problematic. I would > > have thought that 8Mb would be the minimum platform to > > support but we can fiddle the bzip2 code to reduce > > memory usage if we need 4Mb RAM support. Also do we > > want to build in a checksummer into the second stage > > bootloader? If we do MD4 is quick and easy to > > implement, and we can checksum the compressed kernel. > > I can leave it as a compile-in option and turn it off > > until we have a finalised kernel. > > > > Ian > > > > ________________________________________________________________________ > > Want to chat instantly with your online friends? Get the FREE Yahoo! > > Messenger http://uk.messenger.yahoo.com/ > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > > 303_01/01 > > _______________________________________________ > > Theosproject-developers mailing list > > The...@li... > > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > 303_01/01 > _______________________________________________ > Theosproject-developers mailing list > The...@li... > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > |
|
From: <the...@li...> - 2003-08-01 07:36:50
|
Cool! Sorry for my lack of e-mails here - I've been unable to connect for the last couple days. Alls good now. On the 4MB RAM: How about we make this a compile option? (It could be added later if we wanted to skip it now, if it was too much to do.) On the Checksum: That actually sounds great, and would give us the ability to do even a simple security check. I would put a compile option to disable it and leave it in as default, at least when we get a lot closer to the 1.0 release, though it might be neat to see it go through until then too. Thanks! Ben > I have nearly completed a decompressor based upon the > bzip2 utility source code. The problem is not the size > of the decompression code but the 2.7Mb of memory that > the decompressor uses. If we plan on supporting 4Mb > memory platforms this could be problematic. I would > have thought that 8Mb would be the minimum platform to > support but we can fiddle the bzip2 code to reduce > memory usage if we need 4Mb RAM support. Also do we > want to build in a checksummer into the second stage > bootloader? If we do MD4 is quick and easy to > implement, and we can checksum the compressed kernel. > I can leave it as a compile-in option and turn it off > until we have a finalised kernel. > > Ian > > ________________________________________________________________________ > Want to chat instantly with your online friends? Get the FREE Yahoo! > Messenger http://uk.messenger.yahoo.com/ > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > 303_01/01 > _______________________________________________ > Theosproject-developers mailing list > The...@li... > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > |
|
From: <the...@li...> - 2003-07-31 12:49:55
|
Hi all, I just commited the boot stuff - sorry about the delay - I was in transit from Berkeley to South Africa so I haven't had access to a computer for a few days :( I put the files in that were in boot.zip. Cheers, Mark Horner Physics Department University of Cape Town Rondebosch 7700 South Africa Phone: +27 21 650 3366 (office) Phone: +27 83 564 6272 (cellular) Fax: +27 21 650 3342 Homepage: http://hep.phy.uct.ac.za/~horner Co-author: http://savannah.gnu.org/projects/fhsst "It went well. There are no problems, and, as a bonus, it showed that I have a brain!" - Stormers and Springbok backrower CORNE KRIGE speaking after undergoing a precautionary brain scan after a clash of heads during a Super 12 match. On Mon, 28 Jul 2003 the...@li... wrote: > Also, for simplicity's sake (well...maybe not, but for protection at the > very least), the program sections will get their own segment. I.e the > following: > > Text (code): Segment 1 > Data: Segment 2 > Stack: Segment 3 > > I don't know yet if the heap can be given a different segment or not, but if > it can then that would be good too, if not, oh well; it'd be one of those > 'nice features', but the others are requirements. > > Later, > > BRM > > > Let's cut that down to say 1.4MB - that way we can fit it on floppy with a > > little room to spare. > > > > Note: While CD Distributions would probably be what is used when it is > > complete, we shouldn't rule out the ability to boot off a floppy. It's an > > extremely handy tool. ;-) > > > > Also, I'm going to put forth now that we use the ELF format for > > the kernel, > > and as the primary support. Not only do we gain greater access to other > > opensource stuff (e.g. Linux/Unix stuff), but it puts us in a > > good position > > for later. This is one area I'd like to stick with Linux on, and while we > > will be supporting the MS-DOS COM, and Windows COFF, and older > > Unix formats, > > let's start here. (The others will only be for binary-only-distribution > > software compatibility anyway.) > > > > Later, > > > > BRM > > > > > Sounds like a good util to have. > > > I'll bung in the places it needs to change in > > > the boot sector when its complete. > > > if the kernel fits inside 2Mb thats fine. > > > > > > Ian > > > --- Witness <bme...@ca...> wrote: > Sounds > > > cool. > > > > Mark Horner (ho...@hl...) is in charge > > > > of the CVS. > > > > When ready, please send a copy to him to upload to > > > > CVS for initial version. > > > > Please CC meon that e-mail as well. > > > > > > > > As to the kernel size, I don't know. Currently I am > > > > using a dummy file to > > > > add size to my test project. The contents are > > > > simple: > > > > > > > > times 1024*1467 db 0 > > > > > > > > That gives me a file that is 1.44MB for my test > > > > project. > > > > The kernel should fit within that no problem. This > > > > is going to be a size > > > > that will change over time, so it would be good if > > > > we could send it in > > > > through 'make' or something. > > > > > > > > Linux overcomes this through a special program. It's > > > > in > > > > linux/arch/i386/boot/tools. It's a simple C program > > > > that does 3 things. > > > > 1) Validates the bootsector (checks for 0xAA55 at > > > > the correct location) > > > > 2) Concatenates the built-in bootloader, kernel > > > > setup program, and the > > > > kernel into 1 file. > > > > 3) Sets the necessary values at the necessary places > > > > (like the size of the > > > > kernel), ensuring that > > > > those values are in the correct place for the loader > > > > and setup routines. A > > > > similar route would probably be the best way to do > > > > this. > > > > > > > > Karthigan created a Perl script to do, and I created > > > > my own version of the > > > > tool linux uses (it's in the current CVS under > > > > winux/boot/tools). The > > > > current Makefile for the CVS code uses the C tool I > > > > made. > > > > > > > > Note: I'm not pushing the 'linux way' of doing > > > > things. It's just a > > > > suggestion, and info on how others do it. > > > > > > > > Catch you all later! > > > > > > > > Ben > > > > > > > > > -----Original Message----- > > > > > From: The Tigger [mailto:rav...@ya...] > > > > > Sent: Tuesday, July 22, 2003 12:55 PM > > > > > To: Witness > > > > > Subject: RE: Boot Process Developer > > > > > > > > > > > > > > > Ben, > > > > > i've found the multiboot specs on the 'net and > > > > > i am working on making stage 2 so that it can be > > > > > loaded by > > > > > GRUB and multiboot compliant loaders. Stage 1 is > > > > > nearly ready. > > > > > stage 2 will have to be cat'd on the front of the > > > > > kernel. > > > > > Any idea on the size of a compressed kernel? I'll > > > > need > > > > > to hard code the > > > > > kernel size, offset of the kernel entry point in > > > > the > > > > > decompressed image, > > > > > and the size of the kernel BSS. > > > > > (CVS is being a pain to set up so if by thursday i > > > > > can't upload the finished > > > > > files via CVS, i'll email it to you). > > > > > Ian > > > > > --- Witness <bme...@ca...> wrote: > Okay! > > > > > Sounds good to me! > > > > > > > > > > > > And yeah, portability is a problem. > > > > > > > > > > > > Ben > > > > > > > > > > > > > I've only dealt extensivly with IA32 so this > > > > is my > > > > > > > thoughts. > > > > > > > The boot stage 1 does the following. > > > > > > > 1) Load up stage 2 from root of disk. If we > > > > force > > > > > > > stage 2 to be on root we decrease size of > > > > stage 1. > > > > > > > 2) grab RM information. > > > > > > > 3) jump to stage 2. > > > > > > > > > > > > > > Stage 2. (if we want can be cat'd on front of > > > > > > kernel) > > > > > > > 1) setup GDT > > > > > > > 2) Enter PM > > > > > > > 3) Find Kernel > > > > > > > 3a) Read Kernel to mem > > > > > > > 3b) Decompress Kernel. > > > > > > > 4) Setup BASIC IDT. > > > > > > > 5) Provide some basic hardware calls for the > > > > > > Kernel. > > > > > > > 6) Jump to Kernel. > > > > > > > > > > > > > > Portability is going to be VERY difficult. HW > > > > > > > interfacing is going to be totally different > > > > for > > > > > > each > > > > > > > architecture. > > > > > > > > > > > > > > So stage 1 is easy stage 2 is very complex. > > > > > > > i'll look at providing grub compatibility. > > > > > > > Ian > > > > > > > --- Witness <bme...@ca...> wrote: > > > > > > > > Hmmmm....multi-stage boot-loader... > > > > > > > > > > > > > > > > *The following is simply my thought process > > > > > > through > > > > > > > > this issue* > > > > > > > > > > > > > > > > Personally, I would like the bootloader to > > > > do as > > > > > > > > little as it really needs > > > > > > > > to > > > > > > > > do. While a multi-stage bootloader is quite > > > > > > > > appealing - and what most > > > > > > > > everyone > > > > > > > > is using now a days - I'm not sure if it's > > > > what > > > > > > we > > > > > > > > really want to use. > > > > > > > > However, > > > > > > > > in terms of portability (which is important > > > > to > > > > > > the > > > > > > > > project), it may be > > > > > > > > necessary, as otherwise it may bloat the > > > > kernel > > > > > > code > > > > > > > > for some architectures. > > > > > > > > > > > > > > > > Let me give an example. The IA-32 > > > > architecture > > > > > > needs > > > > > > > > to be moved from RM to > > > > > > > > PM, > > > > > > > > and have a number of other things done. > > > > This > > > > > > could > > > > > > > > conceivablely be done by > > > > > > > > the > > > > > > > > kernel, but that would add extra assembly > > > > code > > > > > > to > > > > > > > > the start of the kernel > > > > > > > > for > > > > > > > > _that_ architecture. In comparison, the > > > > Sparc > > > > > > sun4c > > > > > > > > runs a EEPROM BIOS that > > > > > > > > puts the architecture into the PM mode like > > > > > > state > > > > > > > > already (whatever Sun's > > > > > > > > equivalent may be), or at least that is my > > > > > > > > understanding. Thereby, the > > > > > > > > IA-32 > > > > > > > > architecture would have more assembly code > > > > than > > > > > > the > > > > > > > > Sparc for loading it > > > > > > > > simply > > > > > > > > on the grounds of having to do more to get > > > > to a > > > > > > > > given state that could > > > > > > > > otherwise > > > > > > > > be handled by the bootloader. > > > > > > > > > > > > > > > > I guess what I'm trying to say, is that we > > > > > > should > > > > > > > > try to keep the kernel to > > > > > > > > a > > > > > > > > specific set of functionality that is > > > > generally > > > > > > > > common across all > > > > > > > > architectures > > > > > > > > during the boot process. Certainly after the > > > > > > kernel > > > > > > > > has reached a certain > > > > > > > > point > > > > > > > > in the boot process it can start enabling > > > > > > features > > > > > > > > that are architecture > > > > > > > > specific, but the boot stage is probably not > > > > the > > > > > > > > stage to do that, no? > > > > > > > === message truncated === > > > > > > ________________________________________________________________________ > > > Want to chat instantly with your online friends? Get the FREE Yahoo! > > > Messenger http://uk.messenger.yahoo.com/ > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > > Data Reports, E-commerce, Portals, and Forums are available now. > > > Download today and enter to win an XBOX or Visual Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > > 303_01/01 > > _______________________________________________ > > Theosproject-developers mailing list > > The...@li... > > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > > 303_01/01 > > _______________________________________________ > > Theosproject-developers mailing list > > The...@li... > > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Theosproject-developers mailing list > The...@li... > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > |
|
From: <the...@li...> - 2003-07-30 06:34:14
|
where can I get the latest sources for winux. The versions in cvs appear to be old. Thanks, Vinod Rex -----Original Message----- From: the...@li... [mailto:the...@li...] Sent: Tuesday, July 29, 2003 4:18 PM To: the...@li... Subject: [TOSP_Developers] Boot Compression & Checksumming I have nearly completed a decompressor based upon the bzip2 utility source code. The problem is not the size of the decompression code but the 2.7Mb of memory that the decompressor uses. If we plan on supporting 4Mb memory platforms this could be problematic. I would have thought that 8Mb would be the minimum platform to support but we can fiddle the bzip2 code to reduce memory usage if we need 4Mb RAM support. Also do we want to build in a checksummer into the second stage bootloader? If we do MD4 is quick and easy to implement, and we can checksum the compressed kernel. I can leave it as a compile-in option and turn it off until we have a finalised kernel. Ian ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Theosproject-developers mailing list The...@li... https://lists.sourceforge.net/lists/listinfo/theosproject-developers |
|
From: <the...@li...> - 2003-07-29 10:48:14
|
I have nearly completed a decompressor based upon the bzip2 utility source code. The problem is not the size of the decompression code but the 2.7Mb of memory that the decompressor uses. If we plan on supporting 4Mb memory platforms this could be problematic. I would have thought that 8Mb would be the minimum platform to support but we can fiddle the bzip2 code to reduce memory usage if we need 4Mb RAM support. Also do we want to build in a checksummer into the second stage bootloader? If we do MD4 is quick and easy to implement, and we can checksum the compressed kernel. I can leave it as a compile-in option and turn it off until we have a finalised kernel. Ian ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ |
|
From: <the...@li...> - 2003-07-28 05:46:51
|
Yep, that's the plan. We may (at least temporarily) need to borrow the compression code from Linux, at least, unless someone else wants to take a go at it. For size purposes, we probably need it in assembly, though I think Linux does achieve it in C. The decompressor should be limited to at most 1 or 2 tracks (i.e. about 1kb in size). Later, BRM > -----Original Message----- > From: the...@li... > [mailto:the...@li...] > Sent: Sunday, July 27, 2003 2:55 PM > To: the...@li... > Subject: [TOSP_Developers] Kerenel Executable format > > > The kernel as I understand it will be a compressed ELF > file with a bootloader cat'd on the front in order to > decompress the ELF file. If we compress the kernel and > want GRUB/Multiboot compliance this seems to be the > only way forward. However booting off a floppy is very > useful so we probably will need to compress to do so. > > ________________________________________________________________________ > Want to chat instantly with your online friends? Get the FREE Yahoo! > Messenger http://uk.messenger.yahoo.com/ > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > 303_01/01 > _______________________________________________ > Theosproject-developers mailing list > The...@li... > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > |
|
From: <the...@li...> - 2003-07-28 05:31:28
|
Also, for simplicity's sake (well...maybe not, but for protection at the very least), the program sections will get their own segment. I.e the following: Text (code): Segment 1 Data: Segment 2 Stack: Segment 3 I don't know yet if the heap can be given a different segment or not, but if it can then that would be good too, if not, oh well; it'd be one of those 'nice features', but the others are requirements. Later, BRM > Let's cut that down to say 1.4MB - that way we can fit it on floppy with a > little room to spare. > > Note: While CD Distributions would probably be what is used when it is > complete, we shouldn't rule out the ability to boot off a floppy. It's an > extremely handy tool. ;-) > > Also, I'm going to put forth now that we use the ELF format for > the kernel, > and as the primary support. Not only do we gain greater access to other > opensource stuff (e.g. Linux/Unix stuff), but it puts us in a > good position > for later. This is one area I'd like to stick with Linux on, and while we > will be supporting the MS-DOS COM, and Windows COFF, and older > Unix formats, > let's start here. (The others will only be for binary-only-distribution > software compatibility anyway.) > > Later, > > BRM > > > Sounds like a good util to have. > > I'll bung in the places it needs to change in > > the boot sector when its complete. > > if the kernel fits inside 2Mb thats fine. > > > > Ian > > --- Witness <bme...@ca...> wrote: > Sounds > > cool. > > > Mark Horner (ho...@hl...) is in charge > > > of the CVS. > > > When ready, please send a copy to him to upload to > > > CVS for initial version. > > > Please CC meon that e-mail as well. > > > > > > As to the kernel size, I don't know. Currently I am > > > using a dummy file to > > > add size to my test project. The contents are > > > simple: > > > > > > times 1024*1467 db 0 > > > > > > That gives me a file that is 1.44MB for my test > > > project. > > > The kernel should fit within that no problem. This > > > is going to be a size > > > that will change over time, so it would be good if > > > we could send it in > > > through 'make' or something. > > > > > > Linux overcomes this through a special program. It's > > > in > > > linux/arch/i386/boot/tools. It's a simple C program > > > that does 3 things. > > > 1) Validates the bootsector (checks for 0xAA55 at > > > the correct location) > > > 2) Concatenates the built-in bootloader, kernel > > > setup program, and the > > > kernel into 1 file. > > > 3) Sets the necessary values at the necessary places > > > (like the size of the > > > kernel), ensuring that > > > those values are in the correct place for the loader > > > and setup routines. A > > > similar route would probably be the best way to do > > > this. > > > > > > Karthigan created a Perl script to do, and I created > > > my own version of the > > > tool linux uses (it's in the current CVS under > > > winux/boot/tools). The > > > current Makefile for the CVS code uses the C tool I > > > made. > > > > > > Note: I'm not pushing the 'linux way' of doing > > > things. It's just a > > > suggestion, and info on how others do it. > > > > > > Catch you all later! > > > > > > Ben > > > > > > > -----Original Message----- > > > > From: The Tigger [mailto:rav...@ya...] > > > > Sent: Tuesday, July 22, 2003 12:55 PM > > > > To: Witness > > > > Subject: RE: Boot Process Developer > > > > > > > > > > > > Ben, > > > > i've found the multiboot specs on the 'net and > > > > i am working on making stage 2 so that it can be > > > > loaded by > > > > GRUB and multiboot compliant loaders. Stage 1 is > > > > nearly ready. > > > > stage 2 will have to be cat'd on the front of the > > > > kernel. > > > > Any idea on the size of a compressed kernel? I'll > > > need > > > > to hard code the > > > > kernel size, offset of the kernel entry point in > > > the > > > > decompressed image, > > > > and the size of the kernel BSS. > > > > (CVS is being a pain to set up so if by thursday i > > > > can't upload the finished > > > > files via CVS, i'll email it to you). > > > > Ian > > > > --- Witness <bme...@ca...> wrote: > Okay! > > > > Sounds good to me! > > > > > > > > > > And yeah, portability is a problem. > > > > > > > > > > Ben > > > > > > > > > > > I've only dealt extensivly with IA32 so this > > > is my > > > > > > thoughts. > > > > > > The boot stage 1 does the following. > > > > > > 1) Load up stage 2 from root of disk. If we > > > force > > > > > > stage 2 to be on root we decrease size of > > > stage 1. > > > > > > 2) grab RM information. > > > > > > 3) jump to stage 2. > > > > > > > > > > > > Stage 2. (if we want can be cat'd on front of > > > > > kernel) > > > > > > 1) setup GDT > > > > > > 2) Enter PM > > > > > > 3) Find Kernel > > > > > > 3a) Read Kernel to mem > > > > > > 3b) Decompress Kernel. > > > > > > 4) Setup BASIC IDT. > > > > > > 5) Provide some basic hardware calls for the > > > > > Kernel. > > > > > > 6) Jump to Kernel. > > > > > > > > > > > > Portability is going to be VERY difficult. HW > > > > > > interfacing is going to be totally different > > > for > > > > > each > > > > > > architecture. > > > > > > > > > > > > So stage 1 is easy stage 2 is very complex. > > > > > > i'll look at providing grub compatibility. > > > > > > Ian > > > > > > --- Witness <bme...@ca...> wrote: > > > > > > > Hmmmm....multi-stage boot-loader... > > > > > > > > > > > > > > *The following is simply my thought process > > > > > through > > > > > > > this issue* > > > > > > > > > > > > > > Personally, I would like the bootloader to > > > do as > > > > > > > little as it really needs > > > > > > > to > > > > > > > do. While a multi-stage bootloader is quite > > > > > > > appealing - and what most > > > > > > > everyone > > > > > > > is using now a days - I'm not sure if it's > > > what > > > > > we > > > > > > > really want to use. > > > > > > > However, > > > > > > > in terms of portability (which is important > > > to > > > > > the > > > > > > > project), it may be > > > > > > > necessary, as otherwise it may bloat the > > > kernel > > > > > code > > > > > > > for some architectures. > > > > > > > > > > > > > > Let me give an example. The IA-32 > > > architecture > > > > > needs > > > > > > > to be moved from RM to > > > > > > > PM, > > > > > > > and have a number of other things done. > > > This > > > > > could > > > > > > > conceivablely be done by > > > > > > > the > > > > > > > kernel, but that would add extra assembly > > > code > > > > > to > > > > > > > the start of the kernel > > > > > > > for > > > > > > > _that_ architecture. In comparison, the > > > Sparc > > > > > sun4c > > > > > > > runs a EEPROM BIOS that > > > > > > > puts the architecture into the PM mode like > > > > > state > > > > > > > already (whatever Sun's > > > > > > > equivalent may be), or at least that is my > > > > > > > understanding. Thereby, the > > > > > > > IA-32 > > > > > > > architecture would have more assembly code > > > than > > > > > the > > > > > > > Sparc for loading it > > > > > > > simply > > > > > > > on the grounds of having to do more to get > > > to a > > > > > > > given state that could > > > > > > > otherwise > > > > > > > be handled by the bootloader. > > > > > > > > > > > > > > I guess what I'm trying to say, is that we > > > > > should > > > > > > > try to keep the kernel to > > > > > > > a > > > > > > > specific set of functionality that is > > > generally > > > > > > > common across all > > > > > > > architectures > > > > > > > during the boot process. Certainly after the > > > > > kernel > > > > > > > has reached a certain > > > > > > > point > > > > > > > in the boot process it can start enabling > > > > > features > > > > > > > that are architecture > > > > > > > specific, but the boot stage is probably not > > > the > > > > > > > stage to do that, no? > > > > > === message truncated === > > > > ________________________________________________________________________ > > Want to chat instantly with your online friends? Get the FREE Yahoo! > > Messenger http://uk.messenger.yahoo.com/ > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > 303_01/01 > _______________________________________________ > Theosproject-developers mailing list > The...@li... > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 > 303_01/01 > _______________________________________________ > Theosproject-developers mailing list > The...@li... > https://lists.sourceforge.net/lists/listinfo/theosproject-developers > |
|
From: <the...@li...> - 2003-07-27 18:54:52
|
The kernel as I understand it will be a compressed ELF file with a bootloader cat'd on the front in order to decompress the ELF file. If we compress the kernel and want GRUB/Multiboot compliance this seems to be the only way forward. However booting off a floppy is very useful so we probably will need to compress to do so. ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ |
|
From: <the...@li...> - 2003-07-25 07:05:01
|
Let's cut that down to say 1.4MB - that way we can fit it on floppy with a little room to spare. Note: While CD Distributions would probably be what is used when it is complete, we shouldn't rule out the ability to boot off a floppy. It's an extremely handy tool. ;-) Also, I'm going to put forth now that we use the ELF format for the kernel, and as the primary support. Not only do we gain greater access to other opensource stuff (e.g. Linux/Unix stuff), but it puts us in a good position for later. This is one area I'd like to stick with Linux on, and while we will be supporting the MS-DOS COM, and Windows COFF, and older Unix formats, let's start here. (The others will only be for binary-only-distribution software compatibility anyway.) Later, BRM > Sounds like a good util to have. > I'll bung in the places it needs to change in > the boot sector when its complete. > if the kernel fits inside 2Mb thats fine. > > Ian > --- Witness <bme...@ca...> wrote: > Sounds > cool. > > Mark Horner (ho...@hl...) is in charge > > of the CVS. > > When ready, please send a copy to him to upload to > > CVS for initial version. > > Please CC meon that e-mail as well. > > > > As to the kernel size, I don't know. Currently I am > > using a dummy file to > > add size to my test project. The contents are > > simple: > > > > times 1024*1467 db 0 > > > > That gives me a file that is 1.44MB for my test > > project. > > The kernel should fit within that no problem. This > > is going to be a size > > that will change over time, so it would be good if > > we could send it in > > through 'make' or something. > > > > Linux overcomes this through a special program. It's > > in > > linux/arch/i386/boot/tools. It's a simple C program > > that does 3 things. > > 1) Validates the bootsector (checks for 0xAA55 at > > the correct location) > > 2) Concatenates the built-in bootloader, kernel > > setup program, and the > > kernel into 1 file. > > 3) Sets the necessary values at the necessary places > > (like the size of the > > kernel), ensuring that > > those values are in the correct place for the loader > > and setup routines. A > > similar route would probably be the best way to do > > this. > > > > Karthigan created a Perl script to do, and I created > > my own version of the > > tool linux uses (it's in the current CVS under > > winux/boot/tools). The > > current Makefile for the CVS code uses the C tool I > > made. > > > > Note: I'm not pushing the 'linux way' of doing > > things. It's just a > > suggestion, and info on how others do it. > > > > Catch you all later! > > > > Ben > > > > > -----Original Message----- > > > From: The Tigger [mailto:rav...@ya...] > > > Sent: Tuesday, July 22, 2003 12:55 PM > > > To: Witness > > > Subject: RE: Boot Process Developer > > > > > > > > > Ben, > > > i've found the multiboot specs on the 'net and > > > i am working on making stage 2 so that it can be > > > loaded by > > > GRUB and multiboot compliant loaders. Stage 1 is > > > nearly ready. > > > stage 2 will have to be cat'd on the front of the > > > kernel. > > > Any idea on the size of a compressed kernel? I'll > > need > > > to hard code the > > > kernel size, offset of the kernel entry point in > > the > > > decompressed image, > > > and the size of the kernel BSS. > > > (CVS is being a pain to set up so if by thursday i > > > can't upload the finished > > > files via CVS, i'll email it to you). > > > Ian > > > --- Witness <bme...@ca...> wrote: > Okay! > > > Sounds good to me! > > > > > > > > And yeah, portability is a problem. > > > > > > > > Ben > > > > > > > > > I've only dealt extensivly with IA32 so this > > is my > > > > > thoughts. > > > > > The boot stage 1 does the following. > > > > > 1) Load up stage 2 from root of disk. If we > > force > > > > > stage 2 to be on root we decrease size of > > stage 1. > > > > > 2) grab RM information. > > > > > 3) jump to stage 2. > > > > > > > > > > Stage 2. (if we want can be cat'd on front of > > > > kernel) > > > > > 1) setup GDT > > > > > 2) Enter PM > > > > > 3) Find Kernel > > > > > 3a) Read Kernel to mem > > > > > 3b) Decompress Kernel. > > > > > 4) Setup BASIC IDT. > > > > > 5) Provide some basic hardware calls for the > > > > Kernel. > > > > > 6) Jump to Kernel. > > > > > > > > > > Portability is going to be VERY difficult. HW > > > > > interfacing is going to be totally different > > for > > > > each > > > > > architecture. > > > > > > > > > > So stage 1 is easy stage 2 is very complex. > > > > > i'll look at providing grub compatibility. > > > > > Ian > > > > > --- Witness <bme...@ca...> wrote: > > > > > > Hmmmm....multi-stage boot-loader... > > > > > > > > > > > > *The following is simply my thought process > > > > through > > > > > > this issue* > > > > > > > > > > > > Personally, I would like the bootloader to > > do as > > > > > > little as it really needs > > > > > > to > > > > > > do. While a multi-stage bootloader is quite > > > > > > appealing - and what most > > > > > > everyone > > > > > > is using now a days - I'm not sure if it's > > what > > > > we > > > > > > really want to use. > > > > > > However, > > > > > > in terms of portability (which is important > > to > > > > the > > > > > > project), it may be > > > > > > necessary, as otherwise it may bloat the > > kernel > > > > code > > > > > > for some architectures. > > > > > > > > > > > > Let me give an example. The IA-32 > > architecture > > > > needs > > > > > > to be moved from RM to > > > > > > PM, > > > > > > and have a number of other things done. > > This > > > > could > > > > > > conceivablely be done by > > > > > > the > > > > > > kernel, but that would add extra assembly > > code > > > > to > > > > > > the start of the kernel > > > > > > for > > > > > > _that_ architecture. In comparison, the > > Sparc > > > > sun4c > > > > > > runs a EEPROM BIOS that > > > > > > puts the architecture into the PM mode like > > > > state > > > > > > already (whatever Sun's > > > > > > equivalent may be), or at least that is my > > > > > > understanding. Thereby, the > > > > > > IA-32 > > > > > > architecture would have more assembly code > > than > > > > the > > > > > > Sparc for loading it > > > > > > simply > > > > > > on the grounds of having to do more to get > > to a > > > > > > given state that could > > > > > > otherwise > > > > > > be handled by the bootloader. > > > > > > > > > > > > I guess what I'm trying to say, is that we > > > > should > > > > > > try to keep the kernel to > > > > > > a > > > > > > specific set of functionality that is > > generally > > > > > > common across all > > > > > > architectures > > > > > > during the boot process. Certainly after the > > > > kernel > > > > > > has reached a certain > > > > > > point > > > > > > in the boot process it can start enabling > > > > features > > > > > > that are architecture > > > > > > specific, but the boot stage is probably not > > the > > > > > > stage to do that, no? > > > === message truncated === > > ________________________________________________________________________ > Want to chat instantly with your online friends? Get the FREE Yahoo! > Messenger http://uk.messenger.yahoo.com/ > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072 303_01/01 _______________________________________________ Theosproject-developers mailing list The...@li... https://lists.sourceforge.net/lists/listinfo/theosproject-developers |
|
From: <the...@li...> - 2003-07-23 22:51:41
|
Sounds like a good util to have. I'll bung in the places it needs to change in the boot sector when its complete. if the kernel fits inside 2Mb thats fine. Ian --- Witness <bme...@ca...> wrote: > Sounds cool. > Mark Horner (ho...@hl...) is in charge > of the CVS. > When ready, please send a copy to him to upload to > CVS for initial version. > Please CC meon that e-mail as well. > > As to the kernel size, I don't know. Currently I am > using a dummy file to > add size to my test project. The contents are > simple: > > times 1024*1467 db 0 > > That gives me a file that is 1.44MB for my test > project. > The kernel should fit within that no problem. This > is going to be a size > that will change over time, so it would be good if > we could send it in > through 'make' or something. > > Linux overcomes this through a special program. It's > in > linux/arch/i386/boot/tools. It's a simple C program > that does 3 things. > 1) Validates the bootsector (checks for 0xAA55 at > the correct location) > 2) Concatenates the built-in bootloader, kernel > setup program, and the > kernel into 1 file. > 3) Sets the necessary values at the necessary places > (like the size of the > kernel), ensuring that > those values are in the correct place for the loader > and setup routines. A > similar route would probably be the best way to do > this. > > Karthigan created a Perl script to do, and I created > my own version of the > tool linux uses (it's in the current CVS under > winux/boot/tools). The > current Makefile for the CVS code uses the C tool I > made. > > Note: I'm not pushing the 'linux way' of doing > things. It's just a > suggestion, and info on how others do it. > > Catch you all later! > > Ben > > > -----Original Message----- > > From: The Tigger [mailto:rav...@ya...] > > Sent: Tuesday, July 22, 2003 12:55 PM > > To: Witness > > Subject: RE: Boot Process Developer > > > > > > Ben, > > i've found the multiboot specs on the 'net and > > i am working on making stage 2 so that it can be > > loaded by > > GRUB and multiboot compliant loaders. Stage 1 is > > nearly ready. > > stage 2 will have to be cat'd on the front of the > > kernel. > > Any idea on the size of a compressed kernel? I'll > need > > to hard code the > > kernel size, offset of the kernel entry point in > the > > decompressed image, > > and the size of the kernel BSS. > > (CVS is being a pain to set up so if by thursday i > > can't upload the finished > > files via CVS, i'll email it to you). > > Ian > > --- Witness <bme...@ca...> wrote: > Okay! > > Sounds good to me! > > > > > > And yeah, portability is a problem. > > > > > > Ben > > > > > > > I've only dealt extensivly with IA32 so this > is my > > > > thoughts. > > > > The boot stage 1 does the following. > > > > 1) Load up stage 2 from root of disk. If we > force > > > > stage 2 to be on root we decrease size of > stage 1. > > > > 2) grab RM information. > > > > 3) jump to stage 2. > > > > > > > > Stage 2. (if we want can be cat'd on front of > > > kernel) > > > > 1) setup GDT > > > > 2) Enter PM > > > > 3) Find Kernel > > > > 3a) Read Kernel to mem > > > > 3b) Decompress Kernel. > > > > 4) Setup BASIC IDT. > > > > 5) Provide some basic hardware calls for the > > > Kernel. > > > > 6) Jump to Kernel. > > > > > > > > Portability is going to be VERY difficult. HW > > > > interfacing is going to be totally different > for > > > each > > > > architecture. > > > > > > > > So stage 1 is easy stage 2 is very complex. > > > > i'll look at providing grub compatibility. > > > > Ian > > > > --- Witness <bme...@ca...> wrote: > > > > > Hmmmm....multi-stage boot-loader... > > > > > > > > > > *The following is simply my thought process > > > through > > > > > this issue* > > > > > > > > > > Personally, I would like the bootloader to > do as > > > > > little as it really needs > > > > > to > > > > > do. While a multi-stage bootloader is quite > > > > > appealing - and what most > > > > > everyone > > > > > is using now a days - I'm not sure if it's > what > > > we > > > > > really want to use. > > > > > However, > > > > > in terms of portability (which is important > to > > > the > > > > > project), it may be > > > > > necessary, as otherwise it may bloat the > kernel > > > code > > > > > for some architectures. > > > > > > > > > > Let me give an example. The IA-32 > architecture > > > needs > > > > > to be moved from RM to > > > > > PM, > > > > > and have a number of other things done. > This > > > could > > > > > conceivablely be done by > > > > > the > > > > > kernel, but that would add extra assembly > code > > > to > > > > > the start of the kernel > > > > > for > > > > > _that_ architecture. In comparison, the > Sparc > > > sun4c > > > > > runs a EEPROM BIOS that > > > > > puts the architecture into the PM mode like > > > state > > > > > already (whatever Sun's > > > > > equivalent may be), or at least that is my > > > > > understanding. Thereby, the > > > > > IA-32 > > > > > architecture would have more assembly code > than > > > the > > > > > Sparc for loading it > > > > > simply > > > > > on the grounds of having to do more to get > to a > > > > > given state that could > > > > > otherwise > > > > > be handled by the bootloader. > > > > > > > > > > I guess what I'm trying to say, is that we > > > should > > > > > try to keep the kernel to > > > > > a > > > > > specific set of functionality that is > generally > > > > > common across all > > > > > architectures > > > > > during the boot process. Certainly after the > > > kernel > > > > > has reached a certain > > > > > point > > > > > in the boot process it can start enabling > > > features > > > > > that are architecture > > > > > specific, but the boot stage is probably not > the > > > > > stage to do that, no? > === message truncated === ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ |
|
From: <the...@li...> - 2003-07-22 18:27:33
|
Sounds cool. Mark Horner (ho...@hl...) is in charge of the CVS. When ready, please send a copy to him to upload to CVS for initial version. Please CC meon that e-mail as well. As to the kernel size, I don't know. Currently I am using a dummy file to add size to my test project. The contents are simple: times 1024*1467 db 0 That gives me a file that is 1.44MB for my test project. The kernel should fit within that no problem. This is going to be a size that will change over time, so it would be good if we could send it in through 'make' or something. Linux overcomes this through a special program. It's in linux/arch/i386/boot/tools. It's a simple C program that does 3 things. 1) Validates the bootsector (checks for 0xAA55 at the correct location) 2) Concatenates the built-in bootloader, kernel setup program, and the kernel into 1 file. 3) Sets the necessary values at the necessary places (like the size of the kernel), ensuring that those values are in the correct place for the loader and setup routines. A similar route would probably be the best way to do this. Karthigan created a Perl script to do, and I created my own version of the tool linux uses (it's in the current CVS under winux/boot/tools). The current Makefile for the CVS code uses the C tool I made. Note: I'm not pushing the 'linux way' of doing things. It's just a suggestion, and info on how others do it. Catch you all later! Ben > -----Original Message----- > From: The Tigger [mailto:rav...@ya...] > Sent: Tuesday, July 22, 2003 12:55 PM > To: Witness > Subject: RE: Boot Process Developer > > > Ben, > i've found the multiboot specs on the 'net and > i am working on making stage 2 so that it can be > loaded by > GRUB and multiboot compliant loaders. Stage 1 is > nearly ready. > stage 2 will have to be cat'd on the front of the > kernel. > Any idea on the size of a compressed kernel? I'll need > to hard code the > kernel size, offset of the kernel entry point in the > decompressed image, > and the size of the kernel BSS. > (CVS is being a pain to set up so if by thursday i > can't upload the finished > files via CVS, i'll email it to you). > Ian > --- Witness <bme...@ca...> wrote: > Okay! > Sounds good to me! > > > > And yeah, portability is a problem. > > > > Ben > > > > > I've only dealt extensivly with IA32 so this is my > > > thoughts. > > > The boot stage 1 does the following. > > > 1) Load up stage 2 from root of disk. If we force > > > stage 2 to be on root we decrease size of stage 1. > > > 2) grab RM information. > > > 3) jump to stage 2. > > > > > > Stage 2. (if we want can be cat'd on front of > > kernel) > > > 1) setup GDT > > > 2) Enter PM > > > 3) Find Kernel > > > 3a) Read Kernel to mem > > > 3b) Decompress Kernel. > > > 4) Setup BASIC IDT. > > > 5) Provide some basic hardware calls for the > > Kernel. > > > 6) Jump to Kernel. > > > > > > Portability is going to be VERY difficult. HW > > > interfacing is going to be totally different for > > each > > > architecture. > > > > > > So stage 1 is easy stage 2 is very complex. > > > i'll look at providing grub compatibility. > > > Ian > > > --- Witness <bme...@ca...> wrote: > > > > Hmmmm....multi-stage boot-loader... > > > > > > > > *The following is simply my thought process > > through > > > > this issue* > > > > > > > > Personally, I would like the bootloader to do as > > > > little as it really needs > > > > to > > > > do. While a multi-stage bootloader is quite > > > > appealing - and what most > > > > everyone > > > > is using now a days - I'm not sure if it's what > > we > > > > really want to use. > > > > However, > > > > in terms of portability (which is important to > > the > > > > project), it may be > > > > necessary, as otherwise it may bloat the kernel > > code > > > > for some architectures. > > > > > > > > Let me give an example. The IA-32 architecture > > needs > > > > to be moved from RM to > > > > PM, > > > > and have a number of other things done. This > > could > > > > conceivablely be done by > > > > the > > > > kernel, but that would add extra assembly code > > to > > > > the start of the kernel > > > > for > > > > _that_ architecture. In comparison, the Sparc > > sun4c > > > > runs a EEPROM BIOS that > > > > puts the architecture into the PM mode like > > state > > > > already (whatever Sun's > > > > equivalent may be), or at least that is my > > > > understanding. Thereby, the > > > > IA-32 > > > > architecture would have more assembly code than > > the > > > > Sparc for loading it > > > > simply > > > > on the grounds of having to do more to get to a > > > > given state that could > > > > otherwise > > > > be handled by the bootloader. > > > > > > > > I guess what I'm trying to say, is that we > > should > > > > try to keep the kernel to > > > > a > > > > specific set of functionality that is generally > > > > common across all > > > > architectures > > > > during the boot process. Certainly after the > > kernel > > > > has reached a certain > > > > point > > > > in the boot process it can start enabling > > features > > > > that are architecture > > > > specific, but the boot stage is probably not the > > > > stage to do that, no? > > > > > > > > So, I guess using a multi-stage bootloader would > > > > probably be in our best > > > > interest in looking more long term. > > > > > > > > So then, for the IA-32 architecture, what does > > the > > > > boot process need to do? > > > > 1) Stage 1: Load Stage 2 at a given memory point > > > > 2) Stage 2: > > > > a) Load the kernel into memory > > > > b) Set-up an extremely basic GDT, and go into > > > > protected mode (PM) > > > > c) Decompress the kernel (hey, since we're > > using > > > > a multistage, why not go > > > > all out?!) > > > > d) Jump to the kernel > > > > > > > > That should allow the kernel to start out in C, > > as > > > > long as we're careful > > > > what > > > > library function calls we use, as we need to > > define > > > > a lot of the basic ones. > > > > > > > > For the compression: Linux uses a Gzip-based > > > > compression routine. Bzip2 is > > > > suppose to be better from what I've read. To my > > > > knowledge they are the best > > > > out there for compression. So, I guess I'd > > suggest > > > > we look into trying to > > > > find > > > > a simple Bzip2 compression routine (a 'good' not > > > > 'best', at least for now). > > > > I > > > > know we don't need the compression yet, but it's > > > > better to put something in > > > > like > > > > that now, than to try to rewrite everything for > > it > > > > later. > > > > > > > > Sound good? > > > > > > > > Ben > > > > > > > > P.S. I guess I was originally thinking that the > > > > Stage 2 part would be part > > > > of > > > > the kernel init process itself, not simply part > > of > > > > the boot loader. A > > > > foreign > > > > boot loader probably would not have the > > > > decompression in it, so it would > > > > need > > > > to load us to Stage 2 for us to run, and I'd > > guess > > > > for compatibility I'd > > > > rather > > > > have that assumed as part of the kernel. Any > > how, > > > > I'd like to hear some > > > > other > > > > people's thoughts on this. > > > > > > > > > -----Original Message----- > > > > > From: The Tigger > > [mailto:rav...@ya...] > > > > > Sent: Saturday, July 12, 2003 3:52 PM > > > > > To: Witness > > > > > Subject: RE: Boot Process Developer > > > > > > > > > > > > > > > I was thinking along similar lines but having > > a > > > > two > > > > > stage boot process. > > > > > 1) Basic Boot Loader loads up grabs real mode > > > > > information and loads second stage from disk > > into > > > > > memory. Build basic GDT (only 2 selectors) and > > > > jump to > > > > > second stage > > > > > 2) Second stage loads Kernel and sets up more > > > > complex > > > > > IDT/GDT and perform hardware detections. Then > > > > Jumps to > > > > > kernel. > > > > > 3) Kernel starts in PM and sets up paged > > memory as > > > > its > > > > > first task. Then goes off into the multi > > tasking > > > === message truncated === > > ________________________________________________________________________ > Want to chat instantly with your online friends? Get the FREE Yahoo! > Messenger http://uk.messenger.yahoo.com/ > |
2 messages has been excluded from this view by a project administrator.
