OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 1:33 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Decline in resources and practicality in the OS dev space
PostPosted: Fri Oct 30, 2020 12:07 pm 
Offline
Member
Member
User avatar

Joined: Sun Oct 11, 2020 9:46 pm
Posts: 363
Location: United States
I've seen this post.

Recently in the OS development space, there has been a significant decline in resources for beginners.

For example, you can find whole complete tutorials on creating your own bootloader.

For legacy BIOS.

You can find whole complete tutorials on printing text!

For legacy BIOS.

I've been reading some OS development books, and there is a trend in all of the books I've read.
That is, the books will cover the simple subjects (i.e. protected mode jump, little bit of assembly, loading C) however they all do have headers for more advanced subjects (i.e. filesystem, interrupts, memory management, processes) but the pages are blank!
It makes it seem that these books are written by beginners who have only printed HELLO to the screen in QEMU!

I'm working on my own OS, dubbed "microNET". I've implemented interrupts, a VGA driver, keyboard input, serial port debugging, a somewhat-working graphics mode, and a template code UEFI app.

I've been looking for resources for UEFI, such as how to read bytes from disk and whatnot, and besides the "how to make a uefi bootloader" article, that is incomplete, I can't find many resources on UEFI.

Answers I'm looking for in this post:

1) Is the lack of UEFI resources due to a beginner's lack of practicality? Most beginners write OSes that rely on legacy BIOS features, such as VGA text mode, that can't work on real hardware.
2) If not, why is there such a lack of UEFI resources?
3) Does anyone know any UEFI resources, particularly related to loading data from disk to memory?

_________________
Skylight: https://github.com/austanss/skylight

I make stupid mistakes and my vision is terrible. Not a good combination.

NOTE: Never respond to my posts with "it's too hard".


Top
 Profile  
 
 Post subject: Re: Decline in resources and practicality in the OS dev spac
PostPosted: Fri Oct 30, 2020 12:39 pm 
Offline
Member
Member

Joined: Fri Nov 22, 2019 5:46 am
Posts: 590
rizxt wrote:
1) Is the lack of UEFI resources due to a beginner's lack of practicality? Most beginners write OSes that rely on legacy BIOS features, such as VGA text mode, that can't work on real hardware.
2) If not, why is there such a lack of UEFI resources?
3) Does anyone know any UEFI resources, particularly related to loading data from disk to memory?

1.) I'm not sure if I understand you. It is hard to code with the new interface. BIOS is decades old and so a lot of collective experience has been built. Same collective experience, but about UEFI, will be built in the future.
2.) I think it's because it is "new" technology. Off course some projects have already adapted to UEFI (Windows, Linux). But they are either professionals or very many developers. But since beginner's tutorial are written by a bunch of hobbyists, the development of tutorials etc. takes a lot of time. And the complexity of UEFI adds to the problem.
3.) Probably only source code of existing UEFI OS projects.

Greetings
Peter


Top
 Profile  
 
 Post subject: Re: Decline in resources and practicality in the OS dev spac
PostPosted: Fri Oct 30, 2020 1:16 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
rizxt wrote:
1) Is the lack of UEFI resources due to a beginner's lack of practicality? Most beginners write OSes that rely on legacy BIOS features, such as VGA text mode, that can't work on real hardware.
2) If not, why is there such a lack of UEFI resources?
I don't think so. The number of UEFI resources are growing day by day. Just take a look at our wiki. There's also a lot of resource on non-VGA text mode: GOP, Displaying fonts etc. etc. etc.
rizxt wrote:
3) Does anyone know any UEFI resources, particularly related to loading data from disk to memory?
Again, there's some info on the wiki (Asm). Here you can also find an example (in C): LoadFile (using EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) and reading blocks (using EFI_BLOCK_IO_PROTOCOL).

Otherwise read the UEFI specification.

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Decline in resources and practicality in the OS dev spac
PostPosted: Fri Oct 30, 2020 1:57 pm 
Offline
Member
Member

Joined: Fri Nov 22, 2019 5:46 am
Posts: 590
bzt wrote:
Otherwise read the UEFI specification.

I searched the UEFI spec for "disk" but couldn't find useful info. Can you name a sction or page from the spec about disk operations?

Greetings
Peter


Top
 Profile  
 
 Post subject: Re: Decline in resources and practicality in the OS dev spac
PostPosted: Fri Oct 30, 2020 2:02 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Have you looked at the simple file system protocol?


Top
 Profile  
 
 Post subject: Re: Decline in resources and practicality in the OS dev spac
PostPosted: Fri Oct 30, 2020 2:09 pm 
Offline
Member
Member
User avatar

Joined: Sun Oct 11, 2020 9:46 pm
Posts: 363
Location: United States
iansjack wrote:
Have you looked at the simple file system protocol?

Yes, however I can't get readable or commented example code on it...

_________________
Skylight: https://github.com/austanss/skylight

I make stupid mistakes and my vision is terrible. Not a good combination.

NOTE: Never respond to my posts with "it's too hard".


Top
 Profile  
 
 Post subject: Re: Decline in resources and practicality in the OS dev spac
PostPosted: Fri Oct 30, 2020 4:41 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
rizxt wrote:
iansjack wrote:
Have you looked at the simple file system protocol?

Yes, however I can't get readable or commented example code on it...

the specification isn't a tutorial, so it barely contains copy-and-paste ready snippets, but from my own experience, it's really quite easy to get what to do with it, at least simple file system protocol (SFSP). :) here is the snippets from some files of my loader.
0) you need to get the device handle of the device, where your volume resides for opening the needed protocol - be it SFSP for FW-supported FAT volumes or Block I/O protocol for the rest cases. note, in this example, we use the same volume, where the loader comes from, so we locate DeviceHandle through the LoadedImageProtocol instance installed on the image handle of our loader. For the volume, where the OS resides (Boot Volume), locating the handle and overall path is different, both - because you would use Device Path to it and - because it's your burden to parse the format of the volume, that differs from FW supported, of your OS Boot Volume. In most cases, it's non-FAT and firmware can only provide you with the block level access to this device. read below. this example extracts the logo to show on the screen, from the same volume where the loader comes, from the "res" subdirectory of your own "home", inside the "efi" folder. it's how it should have been done - having your own subdirectory inside the "efi" directory, for your (loader! not OS) stuff - loader(s), resources, configuration. it's generally done on a system partition, but as well will work on an ordinary FAT volume.
Code:
/* Opening Loaded Image Protocol instance on our image handle */
   Status = pbs->OpenProtocol(
         ImageHandle,
         &gEfiLoadedImageGuid,
         &gpLoadedImageProtocol,
         ImageHandle,
         NULL,
         EFI_OPEN_PROTOCOL_GET_PROTOCOL
      );
   if(Status != EFI_SUCCESS){
      return ErrorExit(Status, L"ERROR: OpenProtocol() unsuccess on LOADED_IMAGE_PROTOCOL, status: ");
   }

1) now, when you have a device handle, you open an SFSP instance on it. On non-FAT volumes, you use block I/O protocol to get sectors content into memory and your own FS reading code for parsing it and extracting your files. how to obtain the device handle for this case? during installation of the OS, you know, where it goes. so, you get the Device Path for your Boot Volume and put it for example in the FilePathList[1] of the Load Option descriptor for this Load Option. then, having the device path for your Boot Volume, you can open block I/O protocol on it, first getting the handle through the LocateDevicePath() call and then OpenProtocol() on that handle.
Code:
/* Opening Simple FS Protocol on DeviceHandle from the above to obtain file access on the Home Volume - for logo extracting e.g. */
   Status = pbs->OpenProtocol(
         gpLoadedImageProtocol->DeviceHandle,
         &gEfiSimpleFileSystemGuid,
         &gpSfspHomeDrive,
         ImageHandle,
         NULL,
         EFI_OPEN_PROTOCOL_GET_PROTOCOL
      );
   if(Status != EFI_SUCCESS){
      return ErrorExit(Status, L"ERROR: OpenProtocol() unsuccess on SIMPLE_FILE_SYSTEM_PROTOCOL for OSL home volume, status: ");
   }

2) Now, you open the Volume for further file operations:
Code:
/* Opening the Home Volume on the Home Drive - Root Directory */
   Status = gpSfspHomeDrive->OpenVolume(gpSfspHomeDrive, &gpEfiDirHvRoot);
   if(Status != EFI_SUCCESS){
      return ErrorExit(Status, L"ERROR:OPENMEDIA:HOMEVOLUME:STATUS: ");
   }


3) Now, when you want to get some file, and this example extracts a logo, you do this, using gpEfiDirHvRoot pointer:
Code:
/* Opening the Logo .bmp file */
AAA:   Status = gpEfiDirHvRoot->Open(
         gpEfiDirHvRoot,
         &pEfiFileLogo,
         L"efi\\rizxt\\res\\LOGO.BMP",
         EFI_FILE_MODE_READ,
         0
      );
   if(Status == EFI_SUCCESS){
      goto BBB;
   }else if(Status == EFI_MEDIA_CHANGED){   /* trying to reopen HV */
      Status = gpSfspHomeDrive->OpenVolume(gpSfspHomeDrive, &gpEfiDirHvRoot);
      if(Status != EFI_SUCCESS){
         return NULL;
      }else{
         goto AAA;
      }
   }else{
      return NULL;
   }
BBB:

Notice, the retry, because since you last opened the volume, it may have "changed", you may need to reopen it, thus the retry.

All this was done by just reading through the specifuication, so don't deem it "unhelpful", it's pretty helpful.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: Decline in resources and practicality in the OS dev spac
PostPosted: Fri Oct 30, 2020 5:00 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5100
rizxt wrote:
It makes it seem that these books are written by beginners who have only printed HELLO to the screen in QEMU!

That's because those books are written by beginners who have only printed "hello" to the screen in QEMU.


Top
 Profile  
 
 Post subject: Re: Decline in resources and practicality in the OS dev spac
PostPosted: Sun Nov 01, 2020 9:01 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
rizxt wrote:
iansjack wrote:
Have you looked at the simple file system protocol?

Yes, however I can't get readable or commented example code on it...
I got your point, Loading files under UEFI has been added to our wiki. ATM it's a first draft version, updates are welcome.

Cheers,
bzt


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], MichaelPetch and 63 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