32-bit support in the Limine boot protocol?

[juls0730]

Hello Limine developers,

I have been utilizing the Limine bootloader and protocol for my operating system and would like to address a potential enhancement. Currently, The Limine protocol supports only 64-bit. However, I believe that incorporating 32-bit support would greatly benefit developers and users who rely on legacy systems and embedded devices.

By extending Limine's compatibility to include 32-bit architectures, developers like myself would be able to expand the reach of their operating systems and leverage the comprehensive feature set of Limine without resorting to alternative solutions or abandoning Limine altogether. Additionally, I would be interested in contributing to the implementation of 32-bit support within the Limine protocol.

I kindly request your consideration of this proposal and would appreciate any insights or guidance on the feasibility and potential roadmap for adding 32-bit support to the Limine protocol. Such an enhancement would not only streamline the development workflow but also cater to the needs of users who rely on 32-bit systems.

Thank you for your attention to this matter, and I look forward to hearing your thoughts on the possibility of incorporating 32-bit support into the Limine protocol.

Thanks, juls07

[qookei]

I don't think a 32-bit Limine protocol would provide much benefit over using something like Multiboot 2 (also supported by Limine). They provide most of the same functionality, and assuming a properly designed kernel it'd be easy to switch between using one or the other (via a define or such).

[pitust]

I don't think a 32-bit Limine protocol would provide much benefit over using something like Multiboot 2

Limine sanitizes the memory map which makes it less of a minefield compared to Multiboot 2 for one

[juls0730]

@qookei

Hello, While I understand the availability of alternatives like Multiboot 2, I'd like to highlight the benefits of having a built-in 32-bit implementation in the Limine protocol.

Incorporating 32-bit support would simplify development, making builds easier and reducing dependencies. Developers could utilize Limine as a unified solution for both 32-bit and 64-bit systems, saving time and effort. Expanding Limine's compatibility to include 32-bit architectures would broaden its reach to legacy systems and embedded devices. This would allow developers to leverage Limine's feature set without resorting to workarounds or alternative bootloaders.

Furthermore, a built-in 32-bit implementation would enable simpler and safer development for lower-level devices, reducing complexity and ensuring reliable boot mechanisms. Adding 32-bit support to Limine would simplify development, make builds easier, reduce dependencies, expand target devices, and enable simpler and safer development for lower-level devices. Even further, incorporating a 32-bit implementation into limine would reduce the need for repetitive code that effectively does the same thing just for 2 separate platforms.

Thank you for your input, and I hope you'll consider the potential benefits of incorporating 32-bit support into the Limine protocol.

Best regards, juls07

[lukflug]

ChatGPT much?

[juls0730]

no, are my overdrawn replies a bit much?

[lukflug]

Yeah, I apologize that I overzealously and hastily jumped to conclusions.

[juls0730]

no lol, I was definitely overexplaining a bit much, I was trying to drive my point home very hard.

[mintsuki]

Legacy and embedded are not the target audience of Limine and the Limine boot protocol.

As I mentioned elsewhere yesterday, if you need 32-bit support then you're either targetting legacy machines which you probably shouldn't be wasting your time supporting, or you are doing embedded, and making a general purpose OS/kernel for embedded isn't a popular or smart thing to do.

I suggest re-evaluating why you think you need 32-bit support from the Limine boot protocol and whether that is a constructive use of yours or my time. 32-bit for general purpose computing is dead.

As already mentioned, if you believe you need this feature, there is multiboot2 available, or other bootloaders which may be more tailored to the use case you have in mind.

[juls0730]

I understand, thank you for your time, Kindly, juls07.

[sskras]

@mintsuki commented 3 weeks ago:

Legacy and embedded are not the target audience of Limine and the Limine boot protocol.

While I agree about the right to keep the protocol for meeting specific needs (the general purpose OSes in this case), I am shocked to read this:

As I mentioned elsewhere yesterday, if you need 32-bit support then you're either targetting legacy machines which you probably shouldn't be wasting your time supporting, or you are doing embedded, and making a general purpose OS/kernel for embedded isn't a popular or smart thing to do.

[...] 32-bit for general purpose computing is dead.

You despised 32-bit machines and embedded computing as not fitting into general purpose. Wow...

I and @mintsuki clearly use "legacy" and "general purpose" to define different (even if overlapping) things.

To me, general purpose means things that could be found at any home. A lot of the world still has tons of older computers. Then there is a bunch so-called of embedded boards at every second house these days. And density of the latter only increases with time.

And 90% of legacy machines in the infra I managed at my last job were 64-bit ones:

• Compaq AlphaServer GS80
• HP AlphaServer GS1280
• HP 9000 rp4440
• HP Integrity SuperDome
• Sun SPARC V240
• Sun SPARC T1000
• Oracle SPARC M5000
• HP ProLiant the whole G4-G7 line

So such critical response demands to clarify definition of terms both "general purpose" and "legacy". Please :)

[mintsuki]

Hi, @sskras

I don't think I have used those terms in a wrong manner. I just explained why the Limine boot protocol is not targetted at legacy 32-bit systems or embedded systems.

You say I "despised" 32-bit machines and said they don't fit into general purpose. That's not what I said. What I said is that if you're developing a general purpose OS/kernel from the ground up, you should reconsider whether targetting 32-bit systems is a good idea (for a series of reasons I don't want to get into), and that targetting embedded devices with a general purpose kernel isn't necessarily a good idea (in my humble opinion).

TL;DR I was saying "general purpose" referring to the OS being made, not the target systems. You just misunderstood what I said.

In any case this mainly concerns the boot protocol as per issue title, and you're free to run Limine, the bootloader, on IA-32 systems starting with the Pentium Pro onwards.

[sskras]

TL;DR I was saying "general purpose" referring to the OS being made, not the target systems. You just misunderstood what I said.

OK, maybe I misunderstood, or maybe I refuse to keep these two concepts apart. A general purpose OS can be 32-bits just easy. Please, look at Windows, look at Linux, the BSD family. All they (with the exception for some latest versions) has or recently had 32-bit builds.

And the 64-bit machines I mentioned were running 64-bit OSes that are fully legacy (HP-UX 11.11, OpenVMS 8.3, Solaris 10, Linux 2.6). Bits do not define state of the legacy in an OS.

PS. I understand that I go off the topic (according to title of the issue). Just couldn't help myself regarding definition of the terms.

[lukflug]

@sskras I'd say your definition of general-purpose is a bit unusual. I always understood general-purpose as meaning that the device can be used for a wide variety of thing (i.e. be general-purpose). Whether something is found in any home has nothing to do with it. A laptop, or a smartphone, are general purpose, since you can run a wide variety of different programs which do different things. A microcontroller in an electric toothbrush, something found in many households, is not general-purpose. And it would probably not be wise to run the same kind of OS on a toothbrush as you do on an laptop. Given many of these microcontrollers only have a couple of kilobytes of RAM and ROM. On the other hand, there's general-purpose machines not found in most households, such as the aforementioned HP Integrity servers.

[ElectrodeYT]

I would also like to note that most features that make Limine (the boot protocol) different from, say, Multiboot 2, are not very applicable to 32 bit applications, at least on x86. Even for those that are, the cost of implementing them yourself is not very high.

Taking a quick look at the list of requests, the only one which sticks out to me that would make Limine superior on x86_32 systems compared to other protocols would be HHDM, which comes from the fact that Limine always boots into paged mode, however given the small address space on such systems the usefulness of this would be questionable at best. Many other (non-deprecated) flags, such as Paging Mode, would not be applicable to x86_32, as there only is one paging mode.

Sure, you might like getting the ACPI Table addresses yourself, or having Limine bootstrap secondary processors for you, but getting that yourself on x86 is not rocket science, and you might like the sound of things like getting the EFI Tables as well, but on x86_32, chances are you are booting from legacy BIOS, and the chances are also very good that there are no secondary processors to start.

While I will also acknoledge that these arguments could also be used to argument that there is no need for Limine itself in the first place, a project has to draw a line somewhere, and support for a class of CPUs which are not likely to be produced for desktop use ever again seems like a good place to draw said line.

TL;DR: there is no practical reason Limine needs a 32-bit version, at least for x86_32 machines.

[mintsuki]

@sskras

A general purpose OS can be 32-bits just easy. Please, look at Windows, look at Linux, the BSD family. All they (with the exception for some latest versions) has or recently had 32-bit builds.

Linux, Windows, and the various BSDs all predate widespread 64-bit computing and thus had to make do with what they had, which was 32-bit computing.

The Limine boot protocol was made in 2022, 20 years after the initial introduction of x86-64 by AMD.

I fail to create a connection in my mind between the fact that legacy OSes targetted legacy hardware, and the fact that new OSes made in 2023 probably shouldn't bother doing that, since it isn't necessary anymore.

[sskras]

@lukflug, agree re microcontrollers. But what do 32-bits have to do with them? Are they the only form that 32-bit software exists in? Hell no.

There is a lot of older rPis that are 32-bit and can do a lot of things. There is a lot of old laptops running 32-bit Windows and Linux installation.

Bits has nothing to do with the controllers.

And if you would like switch to the argument of things being embedded, part of the community assumes this area covers also the earlier rPis I mentioned. So I am no wrong to say that rPi2 is both a general-purpose and embedded device.

Why discriminate it? :)

[ElectrodeYT]

There is a lot of older rPis that are 32-bit and can do a lot of things. There is a lot of old laptops running 32-bit Windows and Linux installation.

All RPis after the Model 2 (excluding the original Zero and Zero W) are 64-bit capable. I am pretty sure that no one is using an original RPi for desktop use anymore, if anyone used one for that in the first place.

[mintsuki]

@sskras

Why discriminate it? :)

Because the Limine boot protocol was made long after the introduction of that device, which was cheaping out on hardware on its own already, and in general I'd like to avoid promoting the use of 32-bit processors in general computing devices, like Raspberry Pis as you've mentioned.

[mintsuki]

There is a lot of older rPis that are 32-bit and can do a lot of things. There is a lot of old laptops running 32-bit Windows and Linux installation.

All RPis after the Model 2 (excluding the original Zero and Zero W) are 64-bit capable. I am pretty sure that no one is using an original RPi for desktop use anymore, if anyone used one for that in the first place.

@ElectrodeYT As someone that has tried to, they were too slow to be practical desktop replacements, by far.

[sskras]

@ElectrodeYT:

All RPis after the Model 2 (excluding the original Zero and Zero W) are 64-bit capable.

Why do you divert my question to different version of RPi? Even the first RPi version is still used by DIY folks hobbyists.

I am pretty sure that no one is using an original RPi for desktop use anymore, if anyone used one for that in the first place.

And why general purpose should have anything to do with the desktop? Is that a way you define this term – "General Purpose OS is an OS that can run Desktop" ? :)

[lukflug]

@sskras My comment was specifically about the meaning of "general-purpose", not about whether 32-bit should be supported. In that regard, I can only comment on x86. PCs have been 64-bit for a decade now. And many of those laptops that have 32-bit Windows, have a 64-bit processor, but 32-bit UEFI for whatever reason. Making a 32-bit hobby OS on x86 just doesn't make much sense nowadays. It isn't that much different, and, if anything, long mode is easier, due to the larger virtual address space. If you insist on doing 32-bit, Multiboot2 (which Limine supports) is perfectly adequate for that.

[ElectrodeYT]

@sskras

Why do you divert my question to different version of RPi? Even the first RPi version is still used by DIY folks hobbyists.

Because you said:

There is a lot of older rPis that are 32-bit and can do a lot of things.

And why general purpose should have anything to do with the desktop? Is that a way you define this term – "General Purpose OS is an OS that can run Desktop" ? :)

Computers / Devices that one would actually want to use as a Desktop / Laptop / whatever form factor you want from your PC Basically: is it for embedded use only or not?

[sskras]

@ElectrodeYT, thanks for finally defining one term. What about the second one – the embedded? As I said, some folks clearly assume rPi2 to be embedded device. So the readers also need the definition.

[ElectrodeYT]

@sskras I'm not entirely sure that this discussion (which has basically become a giant argument) is even valuable anymore, but if you insist: The Raspberry Pis were never designed to be replacements for normal computers, outside of maybe educational enviroments, although even there many people (/ schools) simply used them headlessly. I am also willing to bet that the absolute vast majority of Raspberries are being used not as normal, day-to-day computers, but as servers, controllers and other things like that.

Sure, there may be reason to use a RPi as a desktop (for example, poor regions like them because they are cheap and require little power), but then you also come across the fact that the boot method for it is also very primitive and simple, and is very much geared towards instantly starting a Linux kernel, making a "normal" bootloader unnecessary. Adding to this, it is unlikely that people will want to multiboot a RPi, and those that do, will find no trouble in simply replacing the SD-Card when necessary.

Also, if you really want to be pedantic about this, since they are AArch64, if you use a EFI-compatiable firmware loader on your RPi, Limine will, in fact boot on it, making this discussion purely about the original RPis, which were far too slow to be usable.

[sskras]

Does anyone know: can part of this thread be converted into discussions? I have things to add :)

[craftyguy]

There are a large number of tablets, etc that have x86_64 CPUs and 32-bit UEFI. We support these types of things in postmarketOS, because it's important to be able to re-use functional hardware.

[mintsuki]

There are a large number of tablets, etc that have x86_64 CPUs and 32-bit UEFI. We support these types of things in postmarketOS, because it's important to be able to re-use functional hardware.

Limine fully supports booting 64-bit kernels (Limine boot protocol, Linux, etc) on IA-32 UEFI hardware with x86-64 capable CPUs.

[craftyguy]

sorry I got confused. there are also armv7 platforms we support (some MS Surface tablets for example), that can do EFI boot.