Get EFI/UEFI Memory Map

[Coconut9]

How can i get EFI/UEFI memory map like BIOS eax=0x0000E820, int 0x15 ?
Also how can detect if the os is running under Bios or EFI/UEFI ?

[no92]

It seems that you haven't done your homework. Just searching for 'UEFI' on the wiki gets me to this page. Getting the memory map in UEFI involves calling a function that will return it to you. To figure out which one exactly it is is your job. Tip: you need a part of the memory map information to exit boot services. Also, judging by the wiki, it would probably take some major hack to get a UEFI (kernel) binary to also be a valid multiboot(2)-kernel at the same time. I haven't seen this done before, and you probably shouldn't be eager to be the first to do it.

All of this goes to say that by doing basic research, it is fairly obvious that you know whether you're running on UEFI or good old BIOS at compile time, as you'll be creating separate binaries.

[zaval]

zero effort. I understand, you want to do great things, but you don't want to mess around learning and routines. this combination always fails.
go and read the UEFI specification. it writes about memory map quite well.

[Scoopta]

It seems that you haven't done your homework. Just searching for 'UEFI' on the wiki gets me to this page. Getting the memory map in UEFI involves calling a function that will return it to you. To figure out which one exactly it is is your job. Tip: you need a part of the memory map information to exit boot services. Also, judging by the wiki, it would probably take some major hack to get a UEFI (kernel) binary to also be a valid multiboot(2)-kernel at the same time. I haven't seen this done before, and you probably shouldn't be eager to be the first to do it.

All of this goes to say that by doing basic research, it is fairly obvious that you know whether you're running on UEFI or good old BIOS at compile time, as you'll be creating separate binaries.

Linux has a compile option (CONFIG_EFI_STUB) that when enabled makes it valid for both UEFI and multiboot.

[Brendan]

Hi,

Linux has a compile option (CONFIG_EFI_STUB) that when enabled makes it valid for both UEFI and multiboot.

Note: Linux doesn't use multi-boot (normally it uses Linux Boot Protocol).


Cheers,

Brendan

[Schol-R-LEA]

Linux has a compile option (CONFIG_EFI_STUB) that when enabled makes it valid for both UEFI and multiboot.

Note: Linux doesn't use multi-boot (normally it uses Linux Boot Protocol).

I would call this splitting hairs, though it is fair to say that it is not so much that Linux running MultiBoot as it is MultiBoot running Linux.

While Linux has the LBP, that is not in and of itself a boot loader; rather, it is a protocol for communicating with a boot loader during the pass-off. It doesn't much care how it is loaded, so long as the loader provides the necessary information and sets the operational mode before transferring control.

MultiBoot was designed specifically with LBP in mind. Most of the oddities of MultiBoot, and of GRUB in particular, are due to the requirements of the Linux initialization. It was written to work with other systems, of course, Windows in particular (though you will not that, last I checked, it chainboots Windows rather than loading it), as being able to boot both Windows and Linux on a single system was the entire point of it, but it is primarily a Linux-oriented protocol.

AFAIK, the 'official' default boot loader for Linux is still LILO, but in practice, the majority of Linux installations have used GRUB since around 2005.

[Rusky]

You seem to be confusing multiboot and grub? All of LILO, Grub, Syslinux, etc. use Linux's boot protocol. All of ones that boot Windows use chainloading. At no point is multiboot involved.

[Schol-R-LEA]

You seem to be confusing multiboot and grub? All of LILO, Grub, Syslinux, etc. use Linux's boot protocol. All of ones that boot Windows use chainloading. At no point is multiboot involved.

GRUB is a MultiBoot loader, and in fact was originally intended as the reference implementation of the MultiBoot protocol - part of the reason its UI is so shallow and minimal is because the expectation was that other implementations would follow. GRUB is, or at least was, meant only to demonstrate how the MultiBoot Protocol works.

Windows is chainloaded on all MB loaders because Windows doesn't support MB, and in fact doesn't work with any loader other than its own. The provision for chainloading was a core feature of MBP from the start, because the whole point was to make it easier for Linux and Windows to exist on the same box. Windows doesn't play well with others, hence the need for chainloading.

What surprises me is that multi-booting - or even single-booting an OS directly on bare metal - is still a thing at all. I would have expected that the use of hypervisors (with a rump OS that just lets you launch and switch between OSes) would be universal by now, but given the massive pain that can be involved in using either HyperV or Xen I suppose I can see why. Also, a lot of people can't afford the memory and disk space to make it feasible - I know I can't - but still, I would expect it to be the rule rather than the exception, even for consumers who would have no need or wish to run multiple systems.

[Rusky]

Chainloading isn't part of MultiBoot, it merely happens to be supported by several bootloaders that also support MultiBoot and the Linux protocol.

(FWIW, I think most people do use VMs for running multiple OSes at this point, and only use rebooting for experimentation or if they need graphics acceleration and don't want to bother with PCI passthrough.)