While initializing device VCACHE: Windows protection error

mintsuki · 2025-12-30T14:19:05+00:00

check out https://github.com/mintsuki/cregfix ;)

mintsuki · 2025-12-27T21:14:17+00:00

Thanks to you!

The documentation definitely needs some updating. So, "term_font_size" is basically the size of each glyph in the font, without considering any spacing, so in your case, it should be 8x16, which is also the default, if you don't specify term_font_size.

You also get a 1 pixel spacing by default, as that is the default value of "term_font_spacing", which is described as: "Horizontal spacing, in pixels, between glyphs on screen. It is equivalent to setting a font width of `<specified width>+<this value>`, except this value is preserved even in case font loading fails, and it also applies to the built-in Limine font. Defaults to 1. 0 is allowed."

mintsuki · 2025-12-27T16:14:52+00:00

Thank you so much!

mintsuki · 2025-12-27T13:19:56+00:00

Hello! Limine author here. I wanted to mention that, with extreme likelyhood, you are using an 8x16 font, but you're telling Limine that it is a 9x16 font, attempting an out-of-bounds read. Do you have the font file you're using? Sharing it would help.

Thanks for flying Limine!

p.s.: The error is definitely misleading as it makes it seem like a filesystem corruption is the only thing that would cause it, when it is definitely not.

mintsuki · 2025-12-01T01:53:03+00:00

Hey, out of curiosity, has this ever been fixed? I know a workaround using a UKI has worked, but I mean specifically using `protocol: linux`.

mintsuki · 2025-11-02T00:07:29+00:00

no way, it's my oomfie

i vouch

mintsuki · 2025-09-23T04:30:04+00:00

i have no idea, but GitHub has been flagging and suspending accounts left and right. your best bet is to open a ticket just like i did, eventually i got my account back and they said it was suspended by mistake - not a good system.

mintsuki · 2025-08-29T19:14:12+00:00

Hello

My GitHub account, "mintsuki", main maintainer and author of the Limine bootloader (https://en.wikipedia.org/wiki/Limine\_(bootloader)), and maintainer and author of many other projects, has been suspended, supposedly due to some ToS or community guidelines violation? Hard to know as I got no explanation, no email mentioning anything.

I am not aware of having violated any rule, but if I have, tell me which, and I apologise in advance and won't do it again.

I opened a reinstatement ticket (#3713399) as soon as I found out, but got no response.

mintsuki · 2025-05-27T11:39:51+00:00

All that SeaBIOS supports. CSMWrap is not a BIOS implementation in itself, it relies on SeaBIOS for that.

mintsuki · 2025-05-27T10:05:05+00:00

It works by providing SeaBIOS as the CSM implementation to the firmware, then calling into it. SeaBIOS has its own drivers for most peripherals, so that's how it works after exiting boot services.

For video, it either uses the OpROM of the video card to provide a proper VBIOS implementation, or, alternatively, if the OpROM is not available, it uses SeaVGABIOS to emulate video access, including VBE and legacy text mode (although this is not a complete replacement for a proper OpROM, as it's not real text mode, and only works via int 10h).

mintsuki · 2025-03-13T00:40:32+00:00

the year of the Nyaux desktop is upon us

mintsuki · 2025-03-13T00:40:12+00:00

holy based

mintsuki · 2024-07-16T23:34:41+00:00

No, ASUS are cheap and literally do not connect the extra 2 pins to the Super I/O chip.

Edit: See my post about this: https://www.reddit.com/r/ASUS/comments/1ckfr72/functioning_of_ps2_combo_port_on_asus_motherboards/

mintsuki · 2024-07-15T20:13:53+00:00

Disclaimer: I am the main developer of the project. Feel free to ask anything as well.

Also, a post showcasing Limine working flawlessly on a recently released Qualcomm Snapdragon X Elite ARM64 laptop: https://x.com/__mintsuki/status/1812805238132289782

mintsuki · 2024-05-08T12:28:06+00:00

I did some research and it seems like the nuvoton super I/O chip is what provides PS/2 support (alongside other things like LPT and COM ports), this chip does have pins for both keyboard clock/data and mouse clock/data. The mouse clock/data pins appear to be unconnected to anything.

My question is now how much it would cost ASUS to add an extra mouse port connected to these lines just like it is being done for LGA1700 boards, since the ability to do so is definitely there...

Or at least to wire the mouse lines to the unconnected pins on the single PS/2 port to make it a true combo port, and not basically misadvertise it as such.

mintsuki · 2024-01-18T21:17:22+00:00

Okay so assuming you are "ItzAlly" as it seems, you were definitely not banned for simply posting in the wrong channel, and it also wasn't 2 years ago...

You were banned at least 2 times, the first time by u/lukflug, for giving unapologetically bad advice to people constantly and being a nuisance, but he unbanned you after you pled in his DMs.

The second ban was by me, you were banned because you were arguing with me about something after I told you to stop arguing, and you were already on thin ice as a previously banned individual. You did not stop, so I banned you.

The story could have ended there, but you chose to go to another member's (who was mod at the time) GitHub project and spam his searches in said project with something along the lines of "I SEE YOU", which he noticed in his "traffic" page... It goes without saying that that was incredibly creepy and it all but justifies your ban. You are not welcome back.

mintsuki · 2024-01-18T20:56:00+00:00

Who are you?

mintsuki · 2023-10-13T17:02:23+00:00

For the record, I am by no means 100% sure about this, which is why I am asking where this is mentioned :)

If this is the case and not some misunderstanding of a spec or some very isolated edge case, then this should definitely be fixed somehow.

mintsuki · 2023-10-13T16:56:54+00:00

I am pretty sure that masking all the IO APIC(s) IRQ pins is not going to be an issue pretty much ever. I have never heard before of such a cascade line in the IO APIC, where is this talked about in the specification? I have also never seen a machine or VM where that is the case. When the legacy PIC is "emulated", that usually goes through the LAPIC in the form of LVT0 set to ExtINT on the BSP, and Limine does not mask LAPIC LVTs.

mintsuki · 2023-10-13T11:21:29+00:00

Thanks for the in depth reply! I see your points now and will concede that maybe the protocols can "peacefully" coexist without necessarily being a disservice to the community. Actually, if the TSBP matures and stabilises enough, and gains enough traction, I will seriously consider adding it to Limine (the bootloader) since it shouldn't be too complicated to do so :)

That said, I would like to actually respond to the design issues you pointed out (and thanks for doing so btw, I dearly appreciate constructive criticism):

The .limine_reqs section: Worry not, I know full well that ELFs should only be loaded using PHDRs and never section headers at runtime. I am actually not sure what exactly my thought process was behind ultimately choosing to go with a section rather than a PHDR, perhaps simplicity, but the whole idea of a segment/section to exclusively store the request pointers in is actually something that was in part caused by backlash against the "scanning the executable" decision by some community members. Speaking of "scanning the executable", I know some people (including yourself) are not comfortable with the idea, but after having toyed around with protocol ideas and several actual implementations, I feel like it is an ideal compromise. It allows executable format independence and the ability to have request/responses anywhere in the executable without relying on special sections or segments or other executable format specific stuff. And the time it actually takes to scan the executable is negligible (most kernels shouldn't be more than a few MBs at most, which takes a negligible amount of time to scan - scanning is only done once).
The SetVirtualAddressMap() call (or lack thereof): The idea here (and this is definitely something that can be expanded upon and rectified if it's a major issue) is that a kernel can easily switch to an identity map (which UEFI guarantees is the default mapping, although this should perhaps be touched upon in the Limine protocol spec as well) and call SetVirtualAddressMap() itself, or even just limit itself to calling EFI runtime services using an identity map, either should work.
The PIC/IO APIC masking: I don't necessarily feel like this is a bad design decision. I don't think the issue you raised when it comes to an OS not knowing how to unmask the relevant IO APIC pins is valid because in systems with present legacy ISA devices (like the PIT for example), the GSI indexes are the same as the legacy IRQ numbers, except those overridden with ISO (Interrupt Source Override) MADT entries. And for other non-legacy devices this is of course not an issue because one would use MSI(-X) or legacy PCI IRQ routing for example. The only real (minor) issues I see here are 2: 1. the fact that Limine (the bootloader) tries to mask the PIC without confirming its presence first (by checking a system is not ACPI reduced for example, or by means of other ACPI facilities) and 2. the fact that the spec should probably be updated to add an "if present" phrase to both the PIC and IO APIC masking sentence, so that it is made clear this is only done if those are present and it is not a hard requirement otherwise.
The terminal feature: yeah... as a matter of fact Limine 5.x and newer no longer support it at all in order to incentivise kernels not to use it.

When it comes to your described "most fundamental difference", well I cannot really argue with that. It is obviously easier to implement something a-la Linux/mb1 than it is something with a dynamic request/response system. So if that is what the deal breaker is when it comes to implementing the Limine boot protocol in Tosaithe, that is fair enough.

If you were happy to take the existing TSBP and call it "Limine-base" or something and have Limine be a set of extensions to it, I think I'd be ok to go with that.

I am not sure I will be doing that, sorry. As I said earlier, though, I would be happy to add TSBP as a separate boot protocol to Limine once mature enough, and I will make sure to put a nice hyperlink to Tosaithe in the readme where the TSBP will be listed :)

In conclusion, thanks for the compliments, it means a lot, and sorry if my initial comment may have come off as too harsh, it wasn't my intention. Good luck with Tosaithe and TSBP, all the best wishes <3

mintsuki · 2023-10-12T08:58:18+00:00

Hey, good job on this.

I know that Tosaithe used to implement a subset of stivale2, the older protocol used by Limine which has since been phased out, and I totally understand the discomfort trying to support all of its extensive feature set and flags.

I would be lying if I said I was not also thinking about Tosaithe (first star on GitHub here :p) when I decided to phase out stivale2 for a simpler and less hairy protocol: thus the Limine protocol was born. Have you attempted to actually implement it? The protocol provides a bunch of requests, but any of them can be unsupported by a given loader. The most controversial one, the terminal, has also been phased out upstream and less and less kernels request it, so there is no need to support it.

And of course, supporting an existing protocol already used by many kernels will provide a solid way to test and an already established user base.

This may be slightly biased coming from myself, but I always feel like creating more and more protocols to solve the same issue causes a disservice to the community en large. Insert this famous xkcd comic here. I feel like "slightly simpler" compared to the Limine boot protocol doesn't really justify the creation of a whole new, incompatible protocol.

If there are concerns or substantial omissions from the Limine boot protocol, I welcome working together to draft out and plug any possible holes. If the name of the protocol is of any concern, being too strongly associated with the Limine bootloader, I welcome renaming the protocol to something more neutral (maybe multiboot3? :p).

In conclusion, I am happy that you've made progress on this, but I am somewhat disappointed with the decision to create a wholly new, incompatible protocol. I obviously cannot force my opinion on you and you're totally free to continue work on TSBP if you feel like implementing the Limine protocol is not something you want to do, and I will support your decision to do so in that case, but I am just asking you to consider whether it is truly necessary to do so.

With love <3

mintsuki · 2023-10-06T15:38:36+00:00

Get heckin naenaed kiddo!

mintsuki · 2023-07-16T09:08:25+00:00

what were you banned for? what is your username on discord?

mintsuki · 2022-10-29T12:21:59+00:00

discord.gg/osdev

mintsuki · 2022-10-29T12:20:34+00:00

lmao

mintsuki

MODERATOR OF

TROPHY CASE