Minix and UEFI, ACPI.

[z4v4l]

Hi there.

Sorry, I am not much aware of Minix internals, but I guess it can't make use of UEFI and ACPI standards now, right? I understand there is no manpower for doing progress in any area, but still the project is alive and so maybe someone is looking into this too? Are there plans to include supoort for those standards?
I am trying to create my own Uefi implementation (on arm and mips), and I am thinking it would be very good to have such a light-weight OS as Minix as my first payload (apart from Uefi applications llike edk-shell of course). At the minimum need it's just about to learn what OS expects from loader - thus an interface between them, but it would be cooler if OS got Uefi-aware so to say, for example didn't pollute Uefi reserved memory, made use of Uefi Runtime Services, took configuration info from it (ACPI tables, OF's device tree).
Can someone briefly outline is this feasible to add that support into Minix, or is it so not suitable for this, that one could just forget about it?) What should I change? What to begin with? At the Minix internal structure I mean. (Because I am not a "microkernel" guy at all))).
And of course, the main question last))) is Minix usable at all on the armv7 land, namely on the Beagle Bone Black target? Because as I understood on mips it isn't.
Thanks.

[Jean-Baptiste Boric]

Hi,

 

Sorry, I am not much aware of Minix internals, but I guess it can't make use of UEFI and ACPI standards now, right?

There's no UEFI support whatsoever, MINIX 3 for now expects an IBM PC compatible computer on i386. This is not much of a problem in practice if we have proper ACPI support, but it's optional and only used for interrupt mapping. On ARM everything is pretty-much hard-coded right now.

While not a hard requirement for UEFI support per se, we do not support GPT or FAT32. The lack of 64 bit support may also be a problem, but it's not unsolvable either.

I understand there is no manpower for doing progress in any area, but still the project is alive and so maybe someone is looking into this too? Are there plans to include supoort for those standards?

There is manpower (not enough, but that's another problem), but volunteers tend to work on what they can and what they want, when they can and when they want. Also historically, due to the nature of the project, the guru developers tended to work on their stuff for long periods of time and dropped huge amounts of commits sporadically. Visibility is steadily improving (GitHub, MINIXcon) but it can be misleading if you are not aware of MINIX's particularities. 

IBM PC compatibility is rapidly getting extinct on modern hardware. MINIX 3 already can't run on recent Mac hardware or on select embedded x86 boards and the list will only grow with time. We'll have to do something about that some day if we don't want to end up scavenging vintage computers in museums. The most straightforward solution I see is making ACPI mandatory and at least parse its tables to stop relying on 35 year old unwritten conventions.

On the ARM side we will need device tree support if we want to outgrow the Beagles. I have a proof-of-concept port for the Raspberry Pi 2/3 that is currently stuck in a pull request on GitHub in part because there's no support for device trees or proper multiple board vendors for now.

Currently I am not aware of anybody working on these subjects, but they will have to be dealt with at some point.

I am trying to create my own Uefi implementation (on arm and mips), and I am thinking it would be very good to have such a light-weight OS as Minix as my first payload (apart from Uefi applications llike edk-shell of course). At the minimum need it's just about to learn what OS expects from loader - thus an interface between them, but it would be cooler if OS got Uefi-aware so to say, for example didn't pollute Uefi reserved memory, made use of Uefi Runtime Services, took configuration info from it (ACPI tables, OF's device tree).

What an OS needs to know to run on a particular piece of hardware is basically :

• where's the RAM,
• where in RAM did the bootloader stored the modules for us,
• what/where are the peripherals, at least for the non-enumerable ones.

UEFI itself can be mostly ignored without too much consequences in practice as most of this information is available in static form (ACPI tables, FDTs or BIOS memory maps for example). As a matter of fact, MINIX 3 can be booted in UEFI mode on x86 using GRUB even though MINIX 3 has no specific UEFI support.

Can someone briefly outline is this feasible to add that support into Minix, or is it so not suitable for this, that one could just forget about it?) What should I change? What to begin with? At the Minix internal structure I mean. (Because I am not a "microkernel" guy at all))).

It depends on how much integration with UEFI you want to achieve.

You will probably first want to replace some hard-coded stuff with ACPI tables/FDT parsing. On ARM you'll want at least to identify the board and parse the memory map from the device tree inside the micro-kernel (that happens mostly inside minix/kernel/arch/earm/pre_init.c), which would be easy enough to do.

From there on, you can either keep replacing hard-coded stuff in drivers, try to interact with the UEFI firmware (listing variables, rebooting, getting/setting the time...) or even try to boot directly from UEFI without an intermediate bootloader, in order of difficulty.

And of course, the main question last))) is Minix usable at all on the armv7 land, namely on the Beagle Bone Black target? Because as I understood on mips it isn't.

I am not aware of the details since I lack the BeagleBone, but currently there are issues running on hardware with the master branch which are in the process of being addressed. Hopefully someone with more information can bring some light on the matter.

What I can say is that my own Raspberry Pi proof-of-concept port worked well enough to run my presentation of the project on it at my school. Running on QEMU should work too.

[z4v4l]

Thank you for the detailed answer. :)
I need to learn more about minix before. Still for me it's much more attractive than trying to deal with that bloated horror as linux.
The only note I can make now, you mention that on ARM, minix would need DT support. Of course, SBC land is using exactly this. But ARM is moving towards ACPI. And in my "project" I am trying to do so as well, thus convert anything possible into ACPI tables. On BBB (doh).)))
Thank you again.)

[bertbr...@googlemail.com]

Hi Jean-Baptiste,

On Saturday, February 25, 2017 at 11:21:38 PM UTC+1, Jean-Baptiste Boric wrote:

Hi,

 

Sorry, I am not much aware of Minix internals, but I guess it can't make use of UEFI and ACPI standards now, right?

There's no UEFI support whatsoever, MINIX 3 for now expects an IBM PC compatible computer on i386. This is not much of a problem in practice if we have proper ACPI support, but it's optional and only used for interrupt mapping. On ARM everything is pretty-much hard-coded right now.

Not even for interrupt mapping, APIC is broken since a longer time. 

 

While not a hard requirement for UEFI support per se, we do not support GPT or FAT32. The lack of 64 bit support may also be a problem, but it's not unsolvable either.

FAT32 would be quite nice, as we could update the kernel + modules on the EFI boot partition, netbsd already have it, but im not aware of the FS abstractions in minix.

 

I understand there is no manpower for doing progress in any area, but still the project is alive and so maybe someone is looking into this too? Are there plans to include supoort for those standards?

<deleted for better readability>  

IBM PC compatibility is rapidly getting extinct on modern hardware. MINIX 3 already can't run on recent Mac hardware or on select embedded x86 boards and the list will only grow with time. We'll have to do something about that some day if we don't want to end up scavenging vintage computers in museums. The most straightforward solution I see is making ACPI mandatory and at least parse its tables to stop relying on 35 year old unwritten conventions.

Yes, the target system list is getting smaller and smaller. However, we run it successful on Lenovo X-series (x210, x230 and x240, the Intel NIC is still not supported => #171) and the Minnowboard (flashing coreboot&seabios instead of TianoCore 64bit EFI). Making Minix3 at least run with more recent hardware (e.g. EFI only _without_ CSM) would be a framebuffer (to get rid of VGA INT calls) and I'm not deep in ARM, but I assume, a framebuffer would help there as well? 

 

I am trying to create my own Uefi implementation (on arm and mips), and I am thinking it would be very good to have such a light-weight OS as Minix as my first payload (apart from Uefi applications llike edk-shell of course). At the minimum need it's just about to learn what OS expects from loader - thus an interface between them, but it would be cooler if OS got Uefi-aware so to say, for example didn't pollute Uefi reserved memory, made use of Uefi Runtime Services, took configuration info from it (ACPI tables, OF's device tree).

What an OS needs to know to run on a particular piece of hardware is basically :

• where's the RAM,
• where in RAM did the bootloader stored the modules for us,
• what/where are the peripherals, at least for the non-enumerable ones.

UEFI itself can be mostly ignored without too much consequences in practice as most of this information is available in static form (ACPI tables, FDTs or BIOS memory maps for example). As a matter of fact, MINIX 3 can be booted in UEFI mode on x86 using GRUB even though MINIX 3 has no specific UEFI support.

Its even part of the Minix3, look at releasetools/x86_hdimage.sh for EFI_SIZE, if you set it to 128 megabytes, it will fetch grub2, build the grub2-efi and adds a fat32 partition as the fourth with the kernel and the modules. If you use the OVM.fd (TianoCore EFI) with the qemu option, you can boot already (being still stuck at the tty.c, as you know, your patch make it work at least with a serial). 

HTH,

Bert

[Jean-Baptiste Boric]

There's no UEFI support whatsoever, MINIX 3 for now expects an IBM PC compatible computer on i386. This is not much of a problem in practice if we have proper ACPI support, but it's optional and only used for interrupt mapping. On ARM everything is pretty-much hard-coded right now.

Not even for interrupt mapping, APIC is broken since a longer time.

So much work to do, so little time... :-(

 

While not a hard requirement for UEFI support per se, we do not support GPT or FAT32. The lack of 64 bit support may also be a problem, but it's not unsolvable either.

FAT32 would be quite nice, as we could update the kernel + modules on the EFI boot partition, netbsd already have it, but im not aware of the FS abstractions in minix.

We don't have a FAT file system server right now. We can probably use mtools to work around it, but that's not as good as native support.

Yes, the target system list is getting smaller and smaller. However, we run it successful on Lenovo X-series (x210, x230 and x240, the Intel NIC is still not supported => #171) and the Minnowboard (flashing coreboot&seabios instead of TianoCore 64bit EFI). Making Minix3 at least run with more recent hardware (e.g. EFI only _without_ CSM) would be a framebuffer (to get rid of VGA INT calls) and I'm not deep in ARM, but I assume, a framebuffer would help there as well?

While a console framebuffer would be nice to have on ARM, we can live without it since UARTs are commonplace. However, serial ports are scarce on modern x86 commodity hardware and booting straight to X11 as a workaround is not acceptable.

Another issue is the lack of USB support on x86. PS/2 keyboards are disappearing and a console framebuffer on x86 would not be very useful without a keyboard to interact with it. We'll need basic USB host controller drivers, which means XHCI, OHCI and UHCI to cover everyone's hardware (at least we can ignore EHCI since they are always paired with a USB 1.0 host controller).

[Sambuc Lionel]

Dear all,


A small slightly related news: if you are looking for a new machine, the Dell OptiPlex 7040 seems pretty happy with Minix out of the box. If you buy one, just go for one which has at least an SATA port available (I have not yet tried to install it on the internal m.2 SSD), and a PCI port for a network card which is currently supported by minix.

I have been looking into the issue of the onboard NIC, and it seems importing the FreeBSD igb driver should be doable. It was done on fork of Minix 3.2.1 using that. Sadly I doubt that code will be re-usable as-is as we introduced libnetdriver since then. Nevertheless, it provide recent hardware which can even be tuned (disabling cores, disabling HT, in order to focus on the max turbo boost speed available), and works without too much tinkering.

I am thinking into starting work on this, as I really would like to use this as my dedicated Minix PC. Is someone already working on it?

Next for me would be to get the xorg intel driver on this machine working, and I think this would improve a lot the situation as far as graphics goes, on a lot of PCs, as the integrated intel GPUs are pretty common nowadays.

Kind regards,

Lionel

> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.