Minimal system requirements to boot ELKS on 8086

[lazylinol]

I am building a computer based on 8086 CPU, which is planned to be somewhat hardware and software compatible with IBM PC XT.

What I've got so far is:

• 80C86 CPU
• 82C84A clock generator
• 82C88 bus controller
• 128K ROM mapped at 0xE0000-0xFFFFF
• 640K of RAM at 0x00000-0x9FFFF
• 16-bit ISA (no 16-bit transfers to 8-bit devices yet, but I'm working on that)
• No BIOS

What is planned to have (from most important to less important):

• Full 16-bit transfers to/from 8-bit devices
• 8259 PIC
• 8254 PIT
• Keyboard controller
• Porting some of the open source BIOS'es available on the net
• DMA controller

At this point it is able to run simple programs, like basic CPU and memory tests, outputting progress to ISA POST card. Of course - nothing interesting yet, since it is not possible to communicate with it in any way.
But once I implement 16 bit transfers to lower portion of the bus - it will be possible to program and use ISA UART cards to interract with the machine, at least in polling mode.

And here to me comes the most interesting part. I would like to ROM boot headless ELKS on it at some point using UART console only, and wondering what are the bare minimum hardware and software requirements for it to start.
Looking at the sources, it seems that I would need at least both PIT and PIC from hardware point of view. Also, ELKS uses int 10h in setup.S, and probably some other interrupts, and since my system does not have any BIOS in ROM I would need to implement those interrupt handlers by myself. Another thing, looks like it is not possible to compile ELKS with headless console driver disabled, keeping serial console only. Per my understanding - headless driver still uses keyboard polling, and since it is not possible to disable it - I will probably need keyboard controller as well.

With that said, my questions are:

• Which hardware from the list of PIT, PIC, and keyboard controller is/are mandatory to have for machine to be able to boot ELKS?
• What software interrupt handlers except int 10h are needed?
• What is the purpose of the headless console driver, in which systems it is useful, and why it is not possible to compile ELKS without it?

Sorry for long post :) and thank you for your attention!

[ghaerr]

Hello @lazylinol,

Sounds like you've got a fun project planned! :) It should be fairly straightforward for you to develop a port to your custom board, as ELKS can be configured for a minimum of dependencies and no BIOS (although I may not remember all the dependencies right now). I've commented below on your various questions; feel free to ask more questions and we'll help you with more specifics as you move forward in your port.

I would like to ROM boot headless ELKS on it at some point using UART console only, and wondering what are the bare minimum hardware and software requirements for it to start.

In general, we now have three "platforms" that are supported using configuration defines: IBM PC and compatibles (using CONFIG_ARCH_IBMPC), the PC-98 Japanese desktop PC (CONFIG_ARCH_PC98), and a ROM-based system based on the 8018X processor (CONFIG_ARCH_8018X). Thus, I recommend that you find the latter define within the sources for more details, as we'd probably want to start by defining that, then changing the code/files that won't work. The 8018X port has no disk but boots from ROM, and runs the headless console out the serial port for communication. All of this would be a good starting point for you.

it seems that I would need at least both PIT and PIC from hardware point of view.

You'll definitely want a PIT as ELKS multitasking depends on it (although even that can be removed with some special defines/work for very prelim development). The 8018X has an internal PIC. You may need to rewrite both these kernel functions for your system. Take a look at elks/arch/i86/kernel/{irq-8018x.c,timer-8018x.c}.

Also, ELKS uses int 10h in setup.S

setup.S isn't used for ROM based systems, so all that code can be ignored. Instead, the startup configuration, including ROM addresses, is statically defined in include/linuxmt/config.h.

looks like it is not possible to compile ELKS with headless console driver disabled, keeping serial console only. Per my understanding - headless driver still uses keyboard polling, and since it is not possible to disable it - I will probably need keyboard controller as well.

You'll want the headless console, but that console driver sits on top of a minimal 'conio' API, which defines functions for reading, writing and polling the "console". In the 8018X case and yours, that would be the serial port. You won't need an interrupt driven keyboard driver. The serial port can be accessed in a non-interrupt fashion if desired.

What software interrupt handlers except int 10h are needed?

You don't really need any, other than the PIT/PIC. The other drivers can be configured to use custom calls as described above.

Also, take a look at Documentation/text/porting-guide.txt.

I hope this helps - feel free to look closer at the source code, and post more questions! :)

Thank you!

[lazylinol]

Good time of the day @ghaerr!

Thank you for your response! It definitely points me to try and follow other direction. I thought that I if build something IBM PC compatible I should compile ELKS as IBM PC too, and never thought about using 8018x as a base build.

I've been playing around with ELKS built as an extension ROM for IBM PC in https://github.com/dbalsom/martypc emulator, and it works flawlessly there. MartyPC even has possiblity to redirect target machine serial port to the host, which I used to test serial console. Although I saw serial output of ELKS booting, I never succedded to have a login prompt there. Altering /bootopts to add serial console didn't help either, but maybe I did something wrong. Also, looking at the disassembly in the emulator, I definitely saw some code that was identical to the one from setup.S and int 10h call, hence my question.

As you suggested, I tried and recompiled ELKS for 8018x - voila - I do not see setup.S code being used, which gives some hope that I won't need int 10h anymore. Does this mean that setup.S is specific to IBM PC only?

And little off-topic, if you were wondering how my build looks like :)

Spoiler warning - big pictures inside

This is the first prototype:

And while it looks more robust, it was total hell to solder it and very slow process overall, so I gave up and now moving everything to breadoards:

Here the process goes much faster!

Arduino for now is used as the clock and RESET source, as well as simple logic analyzer helping to debug, inspired by Ben Eater 6502 build. Later it will be replaced with real 82C84A.

I'll try to keep you posted about my progress.

Thank you!

[ghaerr]

Does this mean that setup.S is specific to IBM PC only?

Yes - that code is responsible to relocate the kernel from its booted location to its final location. In your (and the 8018X) system, the kernel is in ROM so none of that is needed. The reason I'm recommending going the 8018X route is primarily because of ROM, thus no disk access, booting relocations, etc. The actual PIT/PIC, UART etc can all be identical (or not) to the IBM PC, and their source files easily used instead of the 8018X if desired.

[ghaerr]

It definitely points me to try and follow other direction. I thought that I if build something IBM PC compatible I should compile ELKS as IBM PC too, and never thought about using 8018x as a base build.

Nice pictures!

Another option to getting your board running ELKS would be to start with the ROM-only configuration emu86-rom-full.config, which includes a full ROM build of an IBM PC compatible system, but using the ROMFS filesystem, rather than disk. This also shows how to setup where the kernel code and data segments live, etc. That config file is designed to run on emu86 (see emu86.sh), which will emulate a ROM environment and some IBM PC hardware, and the configuration will boot up directly to a shell prompt on COM1. It may run on MartyPC as well, depending on its boot options for ROM, but it seems MartyPC defaults to a mouse on COM1.

You could then go about the process of editing various Makefiles to include (or not) the PIT/PIC and other hardware. The suggestion to use 8018X was only because it is also a ROM environment, but closer inspection reveals that the above config file may be better to start, and its IBM PC compatible (to a degree). Your project is kind of a mix-and-match between a ROM based approach which is used by CONFIG_ARCH_8018X, but hardware used by CONFIG_ARCH_IBMPC.

It's all initially a bit complicated with the many options, but you'll probably want the CONFIG_ROMCODE and CONFIG_IMG_ROM options set, and then look at include/linuxmt/config.h and the various Makefiles controlling the specific hardware you're adding. From a historical point of view, CONFIG_ARCH_IBMPC came first, then the emulated-only emu86 version which uses config.h and CONFIG_ROMCODE internally to that to setup the ROM addresses (bit no overall CONFIG_ARCH_xxx setting), then after that a port-from-scratch of an 8018X SOC, which uses CONFIG_ARCH_8018X to define it, because of the non-IBM PIT/PIC. I hope that helps!

[lazylinol]

Another option to getting your board running ELKS would be to start with the ROM-only configuration emu86-rom-full.config, which includes a full ROM build of an IBM PC compatible system, but using the ROMFS filesystem, rather than disk. This also shows how to setup where the kernel code and data segments live, etc. That config file is designed to run on emu86 (see emu86.sh), which will emulate a ROM environment and some IBM PC hardware, and the configuration will boot up directly to a shell prompt on COM1. It may run on MartyPC as well, depending on its boot options for ROM, but it seems MartyPC defaults to a mouse on COM1.

This is similar to what I did, except that I changed COM port addresses in ELKS so that COM2 becomes COM1 and vice versa to allow using MartyPC COM2 forwarding. This way ELKS produced boot output on the attached serial console, but without actual login prompt. I might still play around with it and try to fix on the emulator, but anyway I'm getting closer with my hardware build, so as soon as I get PIC and PIT working I'm going to experiment on real hardware.
I like CONFIG_ARCH_IBMPC approach more, and probably will stick to that, adjusting it to my specific hardware as you suggested.
For now the only major trouble is that I have only 128K of ROM, which is not enough to fit ROMFS into, but that can be solved by mapping some memory address space to external ISA card which would hold additional ROM.

[ghaerr]

This way ELKS produced boot output on the attached serial console, but without actual login prompt.

Depending on your build, the kernel may be trying to run /bin/init on startup, which requires files in /etc and may just exit otherwise. CONFIG_SYS_NO_BININIT can be set to exec /bin/sh directly after kernel init.

I have only 128K of ROM, which is not enough to fit ROMFS into

The contents of ROMFS can be made smaller by adjusting some of the CONFIG_APP_xxx settings, or possibly editing the elkscmd/Applications file.

[lazylinol]

I'm here with the update.
Long story short - ELKS finally booted on a bare metal 8086 machine:

elks_boot_8086.mp4

To my surpise - it went almost wihout any major troubles. Main issue was the available ROM size, which is 128K, so I had to throw almost everything from ROMFS out to squeeze the only bare minimum into 64K. Another 64K is occupied with the kernel itself, and a tiny simple loader which does some preparations for the kernel, before passing control over to it.
Loader prepares interrupt stubs for int 10h and int 12h, sets up the stack to make a call to ELKS setup code to allow kernel to set up its own int 19h handler, and then calls int 19h allowing kernel to do the rest.

The int 10h stub forwards everything to UART, and for int 12h I had to hardcode it to return true size of available memory (640K), otherwise ELKS could not even start a shell, throwing ENOMEM.
Also, I had to swap COM1 and COM2 port addresses in ELKS sources, because my ISA UART card is probably broken, and does not trigger interrupts for COM1, although COM2 is fine. That's why on the screenshot it says that ttyS0 is at 0x2f8.
Regarding PIT - its channel 0 output is not connected to PIC yet, but ELKS still manages to boot and respond to user input. Not sure what is the impact of having timer not triggering interrupts. Would that cause the scheduler to misbehave? Anyway - PIT is properly programmed by the kernel, I can see channel 0 output pulsing at 83 Hz on the scope, which should really be 100 Hz, but my PIT is clocked with 1MHz instead of 1.19MHz on a real IBM PC.

Initially I though that I would be satisfied reaching this point, but now I'm thinking about connecting a floppy drive :D. Because, why not? This ISA card has FDC and HDD controller on board. But as far as I know, FDC requires DMA controller, and that probaly would be the whole another story.

Thank you for your help and support!

[ghaerr]

ELKS finally booted on a bare metal 8086 machine:

Wow! Very cool indeed!! :) You've done a great job, considering how complicated getting it all running likely was, although we have worked hard in last few years to consolidate the dependencies to a bare minimum.

Are you saying you ended up running some of the ELKS setup.S code, even though you don't technically need to? I guess it turned out the easiest to just setup INT 19h and let the kernel bootstrap somewhat normally. That setup code does use INT 12h and reports that back to the kernel. I can't yet guess why the shell wouldn't run without max mem. Is is possible that substituting the smaller /bin/sash shell might allow a smaller overall footprint, but I don't think ash requires more than about 68k RAM.

For the PIT not producing any interrupts - the headless console uses INT 16h polling (and a kernel timer which wouldn't be working), did you implement that or replace it with something else? The kernel needs the HW timer interrupt for scheduling, but its possible that the system is running without preemptive scheduling and using the serial receive interrupt to essentially keep the system from hanging, as the serial interrupt would cause an exit from the waiting shell read with the keyboard input.

Once you get the PIT running, you'll want to change HZ in include/arch/param.h for an accurate setting.

And yes, it would be fun to hook up an FDC, but the "direct" FD driver hasn't been ported to ELKS yet, although the underpinnings of getting async I/O are being worked on now. The direct FD driver uses elks/kernel/dma.c, and @Mellvik has ported the direct FD driver and dma.c on his fork called TLVC (for strict PC compatibles though). The driver is pretty complicated. Another option would be to bring in some outside "standard" BIOS code into ROM and emulate basic INT 13h, but that's not really nearly as fun or rewarding, I suppose.

A third option which might be really fun would be to take the new SSD driver (elks/arch/i86/drivers/block/ssd.c and ssd-test.c) and hand-code a brand new HD driver from scratch, which shouldn't really be too much effort. The HD could probably use programmed I/O and skip all the more complicated DMA setup issues. To do this, you could probably use ssd.c unmodified and just add an ssd-hd.c for your controller chip. @cocus, who contributed the original SSD code for his 8018x ELKS project (also in ROM), uses the SSD driver to access an SD card on his system through the sub driver in ssd-sd.c. Neither of these methods would require async I/O, but could both work with async I/O automatically when enabled in ELKS.

[ghaerr]

BTW, your mp4 video isn't coming through!

[lazylinol]

Wow! Very cool indeed!! :) You've done a great job, considering how complicated getting it all running likely was, although we have worked hard in last few years to consolidate the dependencies to a bare minimum.

Thank you! Indeed, I had to get through some hardware debugging, but software-wise it was much more smoother process. With little effort and digging into parts of ELKS sources I got a brief idea on how it all works in general, especially for ROM boot process.

Are you saying you ended up running some of the ELKS setup.S code, even though you don't technically need to?

Yes. Looking at the disassembly I saw that setup.S code is present in the resulting kernel Image file, and it would be simpler to hand out control to it as soon as possible, so that it does the rest.
But you say that I did not have to, so I'm wondering what are the other ways to boot up?

I guess it turned out the easiest to just setup INT 19h and let the kernel bootstrap somewhat normally.

Exactly. My loader sets up the stack to call this part to let kernel set up its own int 19h handler:

and after lret returns it back to the loader, the loader just does int 19h, and kernel starts to bootstrap.

That setup code does use INT 12h and reports that back to the kernel. I can't yet guess why the shell wouldn't run without max mem. Is is possible that substituting the smaller /bin/sash shell might allow a smaller overall footprint, but I don't think ash requires more than about 68k RAM.

Without int 12h stub, ELKS was reporting some default amount of memory (can't remember the exact figure), and ash would not start giving errno -12, which appears to be ENOMEM. Maybe sash would run without max mem, but I was stuck and did not even think in that direction. It turned out it was easier just to report correct amount of RAM and the problem was solved :).

For the PIT not producing any interrupts - the headless console uses INT 16h polling (and a kernel timer which wouldn't be working), did you implement that or replace it with something else?

No, I did not implement anything except int 10h and int 12h, and was surprised that ELKS booted up with so little side coding, and was responsive.

The kernel needs the HW timer interrupt for scheduling, but its possible that the system is running without preemptive scheduling and using the serial receive interrupt to essentially keep the system from hanging, as the serial interrupt would cause an exit from the waiting shell read with the keyboard input.

The only HW interrupt present in the system for now is the IRQ4 from UART, probably that is what keeps everything alive.

A third option which might be really fun would be to take the new SSD driver (elks/arch/i86/drivers/block/ssd.c and ssd-test.c) and hand-code a brand new HD driver from scratch, which shouldn't really be too much effort. The HD could probably use programmed I/O and skip all the more complicated DMA setup issues.

That is a really good idea. I'm too lazy to bring DMA to this system, so using PIO is probably the best option. Apart from SSD, would CF card hooked up to a PATA port be possible to use in ELKS in PIO mode?

BTW, your mp4 video isn't coming through!

Oh, yes, sorry about that :(. I'm having troubles with it in FF too, in Chrome it is ok though.

[ghaerr]

But you say that I did not have to, so I'm wondering what are the other ways to boot up?

Actually, I was in error - the setup.S code is still used for CONFIG_ROM versions, even though a much smaller startup sequence is executed due to the lack of need for any relocation and other system hardware specifics. I had also forgotten about the INT 19h stub that is already there - that was written to allow an ELKS image to be created as an PC-compatible BIOS ROM extension and auto-booted.

Without int 12h stub, ELKS was reporting some default amount of memory (can't remember the exact figure), and ash would not start giving errno -12, which appears to be ENOMEM

I'm not quite sure what is happening without INT 12h, as the CONFIG_ROM version in setup.S doesn't appear to call it, and the only other place I remember its used is in the PC boot sector. Given that ELKS uses INT 12h solely to return the max RAM in AX, its possible that somehow the kernel itself thought there wasn't enough RAM to run /bin/sh. The free RAM is displayed at kernel startup, which should be inspected if you ever dive back into this.

I would have to see a full diff to determine why the (supposed polling) keyboard is working without a kernel hardware timer. Perhaps after you get this all running we can get a look at what you've done for future reference.

Keep us posted on your journey into getting an HD connected, as well as the hopeful PIT interrupt so you've got timesharing. I'm happy to help.

[lazylinol]

Finally, after some time and numerous evenings spent debugging, the efforts were rewarded. The ELKS was finally able to boot from a CF card connected to the IDE controller via a CF-IDE adapter.

The program stack is as follows.
I used https://github.com/skiselev/8088_bios as the BIOS. But I had to modify it a bit. Since my 8086 computer does not have PPI, DMA controller, and keyboard controller, the initialization of these functions was skipped. The next step was to make the IDE controller work with an XT-like machine. This is where https://www.xtideuniversalbios.org/ came to the rescue.
In addition, since my system does not have a video adapter too, I wrote a small stub that replaces the video BIOS - emulates MDA video for int 10h, and redirects the text video output to the serial port. This way, I could monitor the BIOS printouts and system booting until ELKS takes over the serial console. This stub is somewhat limited in its capabilities, as you can see in the video below, but it was sufficient for my needs.

The major problem encountered, which took quite some time to figure out, was that the ELKS bootloader could not load the linux kernel, and gave something like

....................................4!

during bootup.
As it turned out, by default, xtide uses disk addressing which is different from NORMAL CHS. After recompiling xtide without LBA and LARGE addressing modes, ELKS finally booted. Now I'm thinking that it might have been possible to boot ELKS without recompiling xtide by simply building my own image with custom HDD image geometry. However, I'm not sure about this, so my guess will have to be tested further.

And then, there comes the beauty of using true 16-bit CPU - it was possible to use one of those old AT-style IDE controllers which are generally 16-bits ISA cards. In case of 8088 that, probably, would not seem to work. Luckily, my card has all-in-one, everything I needed - serial port and IDE controller on a single board.

Also, plugged in through ISA riser, I tried to get NE2000 network ISA card up and running, and even though ELKS was able to recognize and set up the card, actual communication is not possible without DMA, unfortunately.

But overall I'm really pleased to have this machine running ELKS, and had a lot of fun with it. Thank you for your help and support on my journey!

This is the recorded output from the serial port during bootup:

elks_ide_cf_boot.webm

As you can see it is really slow, but what else can you expect from an 8086 running at 4MHz? 😁

And this is the machine itself:

[ghaerr]

Hello @lazylinol,

Very nice, and thanks for the report! :)

I wrote a small stub that replaces the video BIOS - emulates MDA video for int 10h, and redirects the text video output to the serial port. This way, I could monitor the BIOS printouts and system booting until ELKS takes over the serial console.

Nice! Given that the ELKS boot/setup.S only uses INT 10h until the kernel start entry point is called, this is a nice trick.

As it turned out, by default, xtide uses disk addressing which is different from NORMAL CHS.

What does XTIDE use, were you able to determine that? Just a different set of CHS values, or something more different than that?

I tried to get NE2000 network ISA card up and running, and even though ELKS was able to recognize and set up the card, actual communication is not possible without DMA, unfortunately.

I'm not aware that the NE2K driver uses DMA - IIRC it only uses programmed I/O. This means we should be able to get it running on your system. Also, the actual NIC NE2K recognition is quite simple by default (IIRC unless some source ifdefs are modified), so it is not clear that the NE2K chip is being recognized, or did you check that out and it is in fact getting through the initial NIC setup?

Thank you!

[cocus]

Whoa! NICE! Can I ask how you implemented the interface with the NE2k? Mine works, but I'm not sure if the IRQ signal is okay in design (I think it's negated for some reason, but maybe it's okay :) ). Have a look at my schematic: https://oshwlab.com/cocus/80c188eb-sbc. My board doesn't have a disk, but as @ghaerr mentioned, I've implemented a bit-bang SPI that talks to the SD card directly (using the SSD driver).

[lazylinol]

@ghaerr

What does XTIDE use, were you able to determine that? Just a different set of CHS values, or something more different than that?

Initially it uses AUTO, which, I believe, for 2GB CF card would default to LBA translation, and supposedly that makes ELKS bootloader unable to correctly address the disk. But that is just my assumption, I still have to experiment around that, to be sure.

I'm not aware that the NE2K driver uses DMA - IIRC it only uses programmed I/O. This means we should be able to get it running on your system. Also, the actual NIC NE2K recognition is quite simple by default (IIRC unless some source ifdefs are modified), so it is not clear that the NE2K chip is being recognized, or did you check that out and it is in fact getting through the initial NIC setup?

I might have to re-check if MAC reported by NE2K driver is meaningful, but IIRC ktcp was able to assign the IP address to the interface, and that made me think that the network card was recognized.

Just quicky looked up the source for NE2K driver, it seem to use DMA in there. However 3Com 3C509 driver uses the PIO indeed, at least if I read the sources correctly. I remember having some other that NE2K network ISA cards, and there must be some with 3Com chips. I will give it a try and see if that works.

@cocus

Can I ask how you implemented the interface with the NE2k?

TBH, there is nothing too specific. In this machine I have full 16-bit ISA slot, so I just basically put the NE2K card in there. The only change that I had to make was to connect IRQ12 from the ISA slot (IIRC it is the IRQ used by NE2K) to the IRQ7 input of the interrupt controller, and let ELKS know that NE2K will use IRQ7 instead of 12. That was needed because my system does not have second PIC, hence only 8 IRQs are available.
Looking at your schematic, IRQs connections seem to be right, as 80C188 has active HIGH IRQ inputs, similar to classic IBM PC 82C59.

[Mellvik]

Really interesting project!

FWIW - the DMA mentioned in the NE2K driver is really a misnomer, referring to internal DMA on the NIC itself. It's all programmed IO as far as the CPU is concerned. You should be all set really.
BTW the IRQ can be just about anything convenient, depending on the settings/jumpers on the NIC. 12 is usually safe - and the default on many cards.

[lazylinol]

@ghaerr @Mellvik
Been experimenting with networking, PIC, and machine freezes/reboots, and got a question.
How does ELKS handle spurious interrupts? Digging into the IRQ related source code gives me clues that ELKS does not handle them at all. Mainly I'm looking at elks/arch/i86/kernel/irqtab.S, and looks like that the EOI command is being set to PIC(s) regardless, without any checks against respective PIC if triggered interrupt was real or spurious. Or am I looking at the wrong place?

[ghaerr]

How does ELKS handle spurious interrupts?
gives me clues that ELKS does not handle them at all.

For the the issue of handling 8259-specific "spurious" interrupts described in your link: no, ELKS does not read the master PIC's ISR to determine if an interrupt is real or not ("not real" meaning based on the PIC interrupt disappearing before the CPU asks for its vector from the PIC). Actually, I was not aware of this PIC behavior until reading your link. Given that the 8259 will generate a fake IRQ 7, for which there is normally no device driver present, and not having ever seen an "Unexpected interrupt: 7" from the kernel except during device driver development, I'm not sure how much of a problem this is. The link mentions the the kernel must not send an EOI on a spurious interrupt, guessing that this would mean allow the PIC to deliver another interrupt while one is still being processed.

The actual way that ELKS processes IRQs is a bit complicated; I wrote a long wiki page(slightly out of date) on how this works. Basically, a hardware interrupt sets up a kernel entry through _irqit that looks exactly like a system call interrupt, primarily to easily allow the ability for the kernel to switch tasks during a timer interrupt, or similar. After saving all the registers and switching to a kernel stack, interrupts are reenabled and the common routine do_IRQ is called. From here, the device driver procedure associated with the IRQ is called, or "Unexpected interrupt" is displayed. When the routine(s) return, if the IRQ number is from the PIC handling range, an EOI is sent, regardless of whether the interrupt was "Unexpected" or not.

If you want to play with reading the PIC ISR register to modify this or determine whether an actual spurious interrupt is being generated, I would suggest writing that in irq.c::do_IRQ(). There will be a bit of work sending a flag back to the lower level to disable sending an EOI back to the PIC however. We can discuss this more after you've had a more in-depth look at the whole process.

Thank you!

[ghaerr]

More information on early INTR signal removal (see last section): https://www.pcjs.org/documents/manuals/intel/80286/b2_b3_info/
I'm not sure whether this problem is specific to 80286 errata or not.

[lazylinol]

@ghaerr thank you! I'll take a closer look at that.

Meanwhile, I try to understand more about interrupts in ELKS, and this part of code has drawn my attention:

Is there a reason to enable interrupts before calling the C code to handle hardware interrupt? Wouldn't that cause interrupt re-entrancy?

[ghaerr]

Is there a reason to enable interrupts before calling the C code to handle hardware interrupt?

Yes, all kernel "interrupt handlers" run with interrupts enabled. This is good for a number of reasons: 1) disabling interrupts for longer than is absolutely necessary can interfere with time-critical functions, like UART receive character handling or disk sector completion, etc, and 2) allowing higher-priority interrupts to be serviced. In general, interrupts should never be disabled unless absolutely required, and cli/sti pairs are not used to manage differing interrupt request levels, only small critical sections within the kernel (both mainline and device driver).

Wouldn't that cause interrupt re-entrancy?

Technically, yes that could happen. But the sections of the kernel that are actually re-entered are managed by 1) funneling all interrupts through the common _irqit routine, where registers are saved and an appropriate kernel stack is switched to, and 2) the kernel depends on the PIC not allowing any interrupts at a level equal to or lower than any interrupt currently being handled. (This is what the EOI is for, to signal to the PIC that the currently highest priority interrupt has terminated and another may be allowed).

So - the non-device driver area of the kernel will never be re-entered, as _irqit disallows rescheduling of tasks unless the system is processing user land instructions when any interrupt occurs, and the interrupt handlers are not reentered because of the 8259 PIC interrupt disabling of requests <= current interrupt being handled.

[EDIT: the last cli "Disable interrupts to avoid reentering ISR" is talking about the _irqit ISR routine as a whole, not a kernel interrupt handler in C - interrupts are disabled to prevent possible excessive stack usage by not allowing the _irqit routine to fully exit before allowing another interrupt.]

I hope this helps!