Decline in resources and practicality in the OS dev space

[austanss]

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?

[PeterX]

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

[bzt]

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.

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

[PeterX]

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

[iansjack]

Have you looked at the simple file system protocol?

[austanss]

Have you looked at the simple file system protocol?

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

[zaval]

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: Select all

/* 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: Select all

/* 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: Select all

/* 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: Select all

/* 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.

[Octocontrabass]

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.

[bzt]

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