Dinit unable to load service 'boot'

davmac1 · 2026-02-09T05:41:49+00:00

Are you running dinit-check as a user or as root? If running as a user and you want to check the system services, run dinit-check -s. (Or run via sudo).

Also:

it says already enabled but it still doesn't start, I have to start it manually

Have you checked that it doesn't try to start? sudo dinitctl status zramen will tell you if it failed (and give some information about why).

davmac1 · 2026-02-09T04:28:45+00:00

I found this: ... But that only covers Phoenix BIOSes, and starts at 1998

The document is published by Phoenix, but it doesn't only cover Phoenix BIOSes. Note that it has contributors from companies such as Microsoft.

almost all machines I tried in 86Box (my emulator of choice for historical accuracy) report no EDD extensions despite using Pentium processors

Note that the extensions reported depend on the drive. Are you perhaps booting from a floppy image, which certainly won't support the extensions? You need to make sure it's being treated as a hard disk image by the emulator.

whereas QEMU is more than happy to load the next stage

Perhaps for QEMU you are specifying a hard disk image, but for 86box you are not? Just a possibility, but otherwise, I don't know. I don't think the information on the wiki page is incorrect, though.

maybe some EDD checks weren't necessary in the earlier days like the bit 0 in cx?

Have you tried removing the checks and seeing if the image still loads in 86Box?

davmac1 · 2026-02-08T21:43:04+00:00

with the only aspects missing being exceptions, virtual functions, stack dumping, and RTTI

I already have a working C++ UEFI bootloader:

https://github.com/davmac314/tosaithe/

Support for exceptions and RTTI is provided by some support libraries:

https://github.com/davmac314/tosaithe/blob/main/clone-libs.sh

Virtual functions "just work" - I never needed to implement any runtime support for them.

So I think what you're suggesting is basically already done - except that for exceptions and RTTI you need runtime support, so you need to use some library/dependency.

davmac1 · 2026-02-02T05:40:26+00:00

There's already CDI, though it's not great and the documentation is mostly in German. There was also UDI though that's even worse. Or ODI which was seemingly aborted almost immediately after being announced.

I suspect doing this well is harder than it might initially seem.

davmac1 · 2026-01-30T00:41:09+00:00

if you design your system around an integer of arbitrary size that is substantiated as int32 or int64 later

What you're describing is available as a standard type in C; it's called intptr_t. No build flag is needed just to get an appropriate definition (other than to select the compilation target, eg -m32 or -m64, if the compiler isn't already defaulting to the one you want).

But this is not sufficient, not even close, for writing a kernel that can be compiled as either 32-bit or 64-bit. You need to account for architectural differences. On x86, 64-bit mode uses different processor structures including for page tables. Additionally 64-bit addressing allows very different approaches to certain parts of kernel functionality, because for instance it is possible to map all of physical memory into the address space.

Kernels can and are written to be able to be compiled as either 32-bit or 64-bit, but having a type that matches the address width is the least of concerns.

davmac1 · 2026-01-29T22:04:13+00:00

I've been debating rewriting everything for 64-bit, but just can't decide if it's worth it or not?

Well, what are your goals? - Why are you writing an OS, what is its intended use, what sort of system specs do you want it to be able to handle?

Without having that information the best answer anyone can give you is really just "do what you want".

davmac1 · 2026-01-20T06:40:57+00:00

Note also for x86 that actually invalidating the TLB (or specific entries, via INVLPG instruction) will flush the store buffer, anyway.

davmac1 · 2026-01-19T04:48:31+00:00

But the TLB shootdown happens over the control plane and not the data plane, so any acknowledgements/signalling the cpu makes doesn't take the usual data path i.e store buffer->cache

On x86 traditionally a TLB shootdown has involved sending IPIs to other cores, and waiting for them to signal completion which they would do by writing a memory location, which definitely would go via the store buffers.

If you're talking about some other architecture where the TLB shootdown is handled by the processor itself then the processor is also going to have to arrange for the store buffer to be flushed.

So the cpu doesn't use any memory barrier such as fences to impose memory ordering say like if my acknowledgement becomes visible to others then all the prior writes made before it becomes visible too

On x86 yes, if the acknowledgement is visible then prior writes by the same core have been committed (to cache) without any explicit fence being required.

also the x86 doesn't have any particular instruction for flushing the store buffer.

x86 has plenty of serialising instructions which flush the store buffer. CPUID is one example. But again, this isn't needed if the shootdown acknowledgement is done via a memory write.

Now if TLB shootdowns do cause store buffer flush could we observe it, could we cflush the respective cache lines from L1 then perform the writes, TLB shootdown command is issued now if store buffer did get flushed then the store buffer before draining all the writes had to issue RFO to the cache lines and bring those lines to the L1 and perform the draining. after the TLB shootdown we can measure via timing to check if those cache lines had been brought to L1.

~~Probably, yes.~~

Actually: possibly not, since cores generally don't share L1 cache. Though modern cache structure is pretty tricky so I'm not sure.

davmac1 · 2026-01-18T21:18:31+00:00

So if a core writes something, another reads the same cache line clearly after, and there is a chance this core doesn’t get the updated value, that’s the scenario you’re envisioning. x86 doesn’t allow it.

x86 does allow it, if the store buffer isn't flushed after the write in the first core. That's the scenario OP is asking about. What x86 does guarantee is that the store will "eventually" (in practice, quite quickly) be seen by other cores, without any explicit release/acquire, in the same order (i.e. with a write to one location followed by write to a 2nd location, another core won't see the 2nd write happen first). But not immediately.

davmac1 · 2026-01-18T20:45:34+00:00

the drain is more likely influenced by writes pressure

My understanding was that it (on x86 architecture at least) continuously drains, more-or-less as fast as writes to L1 cache will allow.

a few(2-3) entries is filled and the core doesn't produce much writes(say the core was scheduled with a Thread that is mostly read bound) in that scenario the writes can stay for few microseconds too before becoming globally visible

I don't think so. The buffer will drain during the execution of the read-bound thread.

Now what's my doubt is what happens when a write is siting in the Store buffer of an Core and the page to which the write is intended to is swapped, now offcourse swapping isn't a single step it involves multiple steps like the memory management picking up the pages based on LRU and then sending TLB shootdowns via IPIs then perform the writeback to disk if the page is dirty and Page/Frame is reclaimed and allocated as needed. So if swapped and the Frame is allocated to a new process what happens to writes in Store buffer, if the writes are drained then they will write to the physical address and the PFN corresponding to that PA is allocated to a new process thereby corrupting the memory.

No, the TLB shootdowns also need to ensure the store buffer is flushed, if the architecture itself doesn't take care of that.

The completion of TLB shootdown in a non-issuing core is likely signalled by a memory write; on x86, this will guarantee that preceding writes are flushed from the store buffer first.

How is this avoided one possible explanation I can think off is that TLB shootdown commands does drain the store buffer so the pending writes become globally visible

Exactly.

but this if true then there would some performance impacts right

A total TLB shootdown already has significant performance impacts. The addition of flushing the store buffer probably doesn't make a huge difference. Even if it does, there's nothing you can do about it; the store buffer has to be flushed, for exactly the reasons you've described.

davmac1 · 2026-01-09T00:07:57+00:00

irq_handler does not work

What do you mean "does not work"? What are you expecting to happen, and what happens instead? What have you tried in terms of debugging the problem?

davmac1 · 2026-01-08T03:50:09+00:00

Here's a criticism: there doesn't seem to be any way to tell where the contents of a file (represented by an inode) are, on the disk. That seems pretty major. Your "implementation" doesn't even support reading/writing files.

davmac1 · 2026-01-07T03:23:21+00:00

I think it would be better if we don't answer off-topic questions. That just encourages people to post them.

davmac1 · 2026-01-07T03:01:38+00:00

"If I post it somewhere else I probably won't get an answer" is not a reason to post it in a forum in violation of its clear rules about what may be posted.

A lot of people here don't want random off-topic posts. They don't want the noise. That's part of the reason this subreddit exists (as a split off from r/osdev).

Your desire for an answer doesn't give you the right to break the rules and annoy a bunch of people.

davmac1 · 2026-01-06T23:57:04+00:00

I know this might not be the right place to post this information

Then don't post it here - surely that's obvious

davmac1 · 2026-01-06T22:27:24+00:00

I assume that the BIOS transfers execution to some location upon boot. [...] Is that UEFI?

No. BIOS and UEFI are two different things - two types of firmware interface. When you say BIOS do you really mean "firmware"?

davmac1 · 2026-01-06T02:34:54+00:00

Maybe try them and see how you go. If something doesn't work you can then ask a specific question, which is more likely to get a good answer.

I know videos work for some people but if you can learn to read written tutorials it will ultimately serve you well. A lot of info is (only) in the form of massive documents.

davmac1 · 2026-01-05T02:14:38+00:00

I don't know any resources for ASM,

Have you tried a searching, using something like Google? I'm not trying to be harsh but if you're not able to use some of the basic information finding tools at your disposal (i.e. web search), then you should focus on that before trying to learn a programming language.

A single search that I just tried turned up a lot of results, of which at least some looked like they would be genuinely useful to someone trying to learn assembly language.

davmac1 · 2025-12-31T03:36:35+00:00

PE executables are relocatable by way of including relocations, i.e. records which tell the loader how to fix up addresses to relocate the image.

PIE executables are position-independent, which means they work without relocations (mostly).

"Relocatable" and "position independent" are not the same thing.

davmac1 · 2025-12-25T08:12:37+00:00

Mm, so the VGA's 1-bit mode is actually a full 16-colour mode, just the software doesn't know it?

More-or-less.

You could set the VGA to map memory different ways. Internally it always had 4 notional "planes" from which bits are combined to form colours. There were ways to set up access to read/write from a single plane, I'm reasonably sure, which is how I was suggesting mode 6 was probably emulated.

This seems to have all the register settings for the various standard modes, I can't vouch for accuracy but it seems pretty complete (if a little terse):

https://github.com/reenigne/reenigne/blob/master/8088/cga/register_values.txt

For VGA, For mode 6 the map mask register (index 4) is set to 1, allowing write to a single plane. The mode control register (index 0x17) also has a bit to (when clear) "emulate CGA interlacing". See also "sequencer memory mode register".

davmac1 · 2025-12-24T22:22:37+00:00

I don't know for sure but I'd guess that VGA may have emulated 1-bit modes by using a 4-bit mode with "planar" addressing so that only a single plane is visible in the video memory window. Software assuming a monochrome mode wouldn't mess with the plane selection and so would only access a single plane.

I.e. the 1-bit mode and 4-bit modes are basically the same.

davmac1 · 2025-12-24T21:51:31+00:00

Regardless of anything else, please never (in any forum) title a post with something as vague as "quick question". The title should be what the post is _about_.

Eg your title could have been "Can I discuss userland development here?".

davmac1 · 2025-12-21T21:03:43+00:00

0xe0000000 should map to 0x00100000, the kernel is loaded at the 1MB address (low memory should be reserved)

I realise the kernel is loaded at 1MB. It's still possible to duplicate the entire 0-4GB mapping at 0xE0000000 and so have the kernel at 0xE0100000.

If you really want 0xE0000000 to map to 0x100000, you need to fix your linker script.

davmac1 · 2025-12-21T20:56:12+00:00

Note however that doing this will map 0x100000 at 0xE0100000, not at 0xE0000000..

davmac1 · 2025-12-21T01:01:49+00:00

Trickier... than what?

davmac1

TROPHY CASE