I followed the breadcrumbs and found the cause for the Minix3 boot panic 😁
Looks like the problem is with TLB handling, so maybe this explains some Windows issues too?

In my previous post, I found the main suspect on the Minix side to be reload_cr3().
Now taking a look at UniPCemu's source, we see this line in Paging_clearTLB():

1for (TLB_set = 0; TLB_set < 8; ++TLB_set) //Process all possible sets!

However, the TLB_usedlist_head array is defined as having 16 entries both in headers/cpu/paging.h and in cpu/paging.c (via the setsize variable).
I just went and changed that loop size from 8 to 16 and whaddya know, that did the trick 😁

mr.cat wrote on 2021-11-19, 21:31:

I followed the breadcrumbs and found the cause for the Minix3 boot panic :D Looks like the problem is with TLB handling, so mayb […]
Show full quote

superfury wrote on 2021-10-09, 20:41:

Hmmm... Disabling the memory cache entirely also makes Windows 9x crash in exactly the same way as before (with the cache enable […]
Show full quote

Hmmm... Disabling the memory cache entirely also makes Windows 9x crash in exactly the same way as before (with the cache enabled).
So the issue is actually not in the cache itself, but probably in one of the other affected areas, probably the BIU itself?
Or perhaps something else that's changed? Hmmm...
Edit: Hmmm... Reverting the BIU to no longer split the memory accesses for prefetching (always using the same cache instead of double caching) and disabling the caching of multiple bytes at once seem to have no effect. It will still ned up at the invalid instruction with trap and sign flags being set (which isn't supposed to happen)...
So the search for the error continues...
Edit: OK. So the cause seems to have been the physical memory block repeated read optimization, which remembers if the last access to a physical memory is to skip the MMIO devices mapping for the most recently used 4K block of memory.
When disabling said optimization, Windows 98 at least seems to reboot correctly?

I followed the breadcrumbs and found the cause for the Minix3 boot panic 😁
Looks like the problem is with TLB handling, so maybe this explains some Windows issues too?

In my previous post (see above), I found the main suspect on the Minix side to be reload_cr3().
Now taking a look at UniPCemu's source, we see this line in Paging_clearTLB():

Copy code to clipboard

1for (TLB_set = 0; TLB_set < 8; ++TLB_set) //Process all possible sets!

However, the TLB_usedlist_head array is defined as having 16 entries both in headers/cpu/paging.h and in cpu/paging.c (via the setsize variable).
I just went and changed that loop size from 8 to 16 and whaddya know, that did the trick 😁

Well, managed to get those cache issues fixed (the cause wasn't the cache itself but instead the remembering('caching') of the last accessed memory or ROM access was causing issues. So that cache part has been disabled for now(it was causing the Windows reboot issues after detecting hardware)). Then found the VGA memory aperture's bottleneck and managed to optimize it (the memory accesses being reduced to 0.5% for the MMU memory accesses themselves (VGA reduced from ~0.5% CPU usage to ~0.02%).

Implemented those 8 to 16 entries in the paging unit. Also changed said number to a define at the top (for ease of implementation) with all those locations using it.

OK. WIndows NT 4.0 changed alright: I now get a NULL segment dereference during a MOV instruction, then another reset?
It's some data segment:offset dereference. And because the segment register is a NULL (0x0000-0x0003 without P-bit set), it reboots?
Edit: OK. It's some MOV instruction using a CS: prefix override. So it's faulting on trying to access something on the CS segment? CS is F000, so it's probably running the BIOS ROM code in the cached RAM.
Looking at the CPU mode, it's indeed in real mode...
The CS access rights in the descriptor cache is 0x9B...
The access rights themselves for CS seem to be actual 0x9B(not writable, which it should be), instead of being properly executable/read/write as in actual real mode (as undocumented behaviour for the Pentium-compatible CPUs).
Edit: Fixed that one. Still crashing NT 4.0 though.

With Minix 3.3.0, running setup from the bash shell causes it to hang still? Directory listing (ls) works though. The echo program also works.

superfury wrote on 2021-11-22, 02:50:

With Minix 3.3.0, running setup from the bash shell causes it to hang still? Directory listing (ls) works though. The echo program also works.

The boot was moving at a glacial speed for me, so I never got as far as having a shell.
There could be some differences between the Minix3 versions.
Besides Minix, there are other small OSes out there that could be used as test cases (HelenOS, KolibriOS, Genode...).

EDIT: Yup, 3.3.0 seems to work (or at least, I now get a shell).
I was previously using a customized git version, it got stuck at launching the "random" service.

mr.cat wrote on 2021-11-22, 06:04:

The boot was moving at a glacial speed for me, so I never got as far as having a shell. There could be some differences between […]
Show full quote

superfury wrote on 2021-11-22, 02:50:

With Minix 3.3.0, running setup from the bash shell causes it to hang still? Directory listing (ls) works though. The echo program also works.

The boot was moving at a glacial speed for me, so I never got as far as having a shell.
There could be some differences between the Minix3 versions.
Besides Minix, there are other small OSes out there that could be used as test cases (HelenOS, KolibriOS, Genode...).

I did fix one other bug besides the 8 to 16 entry TLB bug: transitioning to real mode on the Pentium and to protected mode from real mode properly ignores the CS access rights in real mode (for Pentium processors and up). Perhaps that's the difference?
I'm using the 3.3.o iso from the minix website (latest official release afaik).

mr.cat wrote on 2021-11-22, 06:04:

The boot was moving at a glacial speed for me, so I never got as far as having a shell. There could be some differences between […]
Show full quote

superfury wrote on 2021-11-22, 02:50:

With Minix 3.3.0, running setup from the bash shell causes it to hang still? Directory listing (ls) works though. The echo program also works.

The boot was moving at a glacial speed for me, so I never got as far as having a shell.
There could be some differences between the Minix3 versions.
Besides Minix, there are other small OSes out there that could be used as test cases (HelenOS, KolibriOS, Genode...).

EDIT: Yup, 3.3.0 seems to work (or at least, I now get a shell).
I was previously using a customized git version, it got stuck at launching the "random" service.

Just tried KolibriOS. It seems to boot into the desktop. It's running very slowly (though managed to run the SHELL 0.7.4 program). It displays 'Shell 0.7.4

Type 'help' for help. Input seems to work, but slowly?

It only displays about 1/4 of the screen (whereever the mouse cursor is at)?
Edit: It even has Dosbox 🤣 Let's see if it runs...
Edit: nope. not even in Qemu? Dosbox's Kolibri build is broken apparently?

Just finished implementing the i450gx basic chipset (it's simply dual PCI bridges (82454GX PCI Bridge, aka PB configuration space in PCI (ID=8086:84C4), one being the Compatiblity PB and one being the Auxilliary PB) with dual Memory Controller (MC, 82453GX Memory controller chips using the documented PCI configuration space(ID=8086:84C5)) chips connected for 8GB RAM to be supported).

Although I can't find any i450gx BIOS to test it with yet.
Edit: OK. The SIO.A southbridge is now also implemented (mostly).

I'm still wondering about the BIOS flash ROM, though? If it's an Intel flash ROM, it should be write-protected somehow? But the i430fx/i440fx chipsets have a write-protect bit in the southbridge, while the i450gx chipset doesn't seem to have any? Or is the BIOS ROM not flash but a ROM chip?

Anyone knows more about the i450gx chipset?

Nice going, I won't be requiring a quadcore guest anytime soon though 😁
About that Kolibri DOSBox test, it's not broken because it does run in qemu (and at least "dir" works there). But I couldn't get Kolibri itself to run in UniPCemu (it hangs when detecting the CPU?)

EDIT: The Kolibri hang seems SeaBIOS related (there's no such hang with ND6I0218.AWD and 440fx).

With the latest commits, an Intel 28F004BV-T BIOS flash ROM chip has been added to the i450gx motherboard.

I did find an BIOS to use, but it still needs to be flashed. Perhaps I can use the i440fx BIOS ROM, expand it to proper 512KB ROM (by adding zeroes to the start of it) and booting it using that BIOS ROM to run the floppy disk I made on the i440fx chipset emulation (from a blank IMD disk image, running the disk writing software from IBM to create the BIOS updating floppy disk). I know it does actually boot. The last time I tried that i440fx BIOS on the i450gx it did start to read the floppy disk.

The BIOS chip I based on the sparse information we have (after communicating with Trawn on IRC about it). He made a picture of the ROM chip on his IBM PC server 704 machine: http://www.xin.at/thrawn/pics/hw/ibm-pcserver … -IntelFlash.jpg

Just actually saw that it's an AP450GX motherboard.
And I do remember viewing specs for those, but thought it wasn't the plain 450gx motherboard I was emulating.... 😖
Edit: Indeed: https://manualzz.com/doc/23566766/intel-ap450 … chnical-product , page 59 table 3.1

But the layout of the flash ROM is different from what the documentation I found says ( https://www.digchip.com/datasheets/parts/data … 8F004BVT-80.php )?

Just fixed a memory leak (found when testing the i450gx running the coreboot BIOS). When a CPU was resetted (other than the BSP CPU), it would clear the memory buffers of all other CPUs as well. And for CPUs 1-3, it would even clear the RAM of whatever followed the CPU structures in memory! (for the size of 1-3 CPU data structures in total) 😖

Luckily the zalloc memory allocator gives a message about that! 😁

Edit: Just found some other overflow bugs, causing the i450gx to overflow the memory mapping buffer when setting the F0000-FFFFF range (writing only the last 16KB of that range and over the 80000-8FFFF range and 3 extra bytes of memory after the table, instead of the proper range).

OK. Now, with the chipset default values loaded as well, it should be basically working.

But the only BIOS I'm getting to boot on it is the Turbo XT BIOS, which has booting problems(floppy containing MS-DOS with flashing software from IBM for the BIOS I need, made on the i440fx). Also the 8042 isn't setup correctly, missing IRQ for keyboard as well as leaving it disabled.

Kind of a chicken-and-egg issue here.

Edit: Managed to get the i440fx chipset mapped into the i450gx chipset. The i440fx responds normally, with the i450gx only responding to the PAM registers. Both i440fx and i450gx PAM registers are shadowed onto each other when written. So putting any memory area in RAM mode does the same on the opposing chipset. The same for PCI mode. The only exception is that when writing the i450gx PAM registers and setting it up for unmapped mode(unmapping the RAM isn't supported on the i440fx chipset), it will map and shadow the i440fx PAM registers to PCI mode instead (which is the closest thing in this case to 'unmapped').

Edit: Just modified the RAM-mapping PAM registers to properly come from the MC chip instead of the second PB chip. So it was retrieving and writing the registers for the high memory area (4GB-8GB) instead of the proper MC chip ones.
That should fix any RAM mapping issues with the i450gx and i450gx emulating a i440fx.

Btw, the MC chips are the Memory Controller chips. And the PB chips are the PCI Bridge chips.

Just modified the PCI configuration spaces to use an unique ID to identify the configuration space being updated, while registering registers the device number and function number on bus #0 (other buses aren't supported yet).

Also, the i450gx now also supports i440fx IO APIC setting shadowing in both directions (when either the i440fx or i450gx is changed, the other is updated based on it when using the i440fx emulation option).

I've also added a i450gx southbridge that uses a 82375SB PCEB and 82374SB ESC chipset. Those can be configured from the i450gx settings menu and through the settings file. So it now supports that southbridge besides the SIO.A southbridge. The i440fx shadowing runs with both southbridges.

Finally, I've modified the PCI configuration spaces to get registered using an unique ID. That ID is (after registering it for the first time) linked to the PCI space entry itself, allowing the emulator (when needed) to update and change the linked PCI configuration space and their linked device/function ID (as needed). Said ID is also the only piece of identifying information given to the change handlers now (instead of device and function ID), making changing the location without changing the handlers easier to modify. It also allows the configuration spaces to change locations on the root bus (no other buses are supported in PCI yet) during run-time if needed. It also simplifies dynamic registration of PCI entries (like with or without i440fx/i430fx chipset for example (i430fx with i450gx isn't used atm, nor supported by the PCI configuration change handlers themselves)).

I do wonder about the i450gx device IDs, though. The i440fx BIOS doesn't seem to see the installed northbridge at all? And it also completely ignores the southbridge on the PCI device listing (it only lists the IDE device on device 1 function 1 (of the PIIX chip that's emulated))?
Perhaps the flashing utility on the IBM floppy ignores the PCI space somehow? Or because the BIOS can't update the flash ROM (which is a i450gx 512KB ROM in this case) it won't report it as the flashing software expects it (or it's perhaps hardcoded inside the BIOS ROM that it's the 128KB Intel one instead of 512KB Intel one)?

Edit: Just found some bugs in the flash ROM emulation when not a 128KB flash ROM (512KB in this case) that caused writes to the flash ROM not to be handled. This of course needs to be handled to be supported properly (required for the flash ROM to be detected at all and properly issuing commands to it, as well as identification).

Just fixed a bug in the PCI device number being used to index into the PCI device array directly, instead of checking the PCI device it's currently checking for a registered match. So anything past the amount of registered devices in the device number wasn't properly visible when reading or writing PCI configuration data from said data areas.

Just adjusted the zalloc memory allocator to be able to support 64-bit memory allocations on supported platforms.

I've also adjusted the MMU to be able to properly handle the 64-bit memory allocations required for the i450gx, now properly supporting the usage of 8GB RAM on said architecture. It was previously limited to just under 4GB RAM instead.

Weird... With the current commits of UniPCemu, somehow Windows 3.1 isn't able to install anymore (apparently due to HDD issues somehow)? Booting the last installation causes all kinds of weird errors to pop up in dialog boxes (like progman.exe having registry issues etc.)?
That didn't happen before?

Reinstalling it fails at disk 1, with what seems to be HDD issues (ATA harddrive issues somehow)?

OK. Just added a slight improvement to the 8259A PIC: The 8259A PIC now supports level-triggered mode, along with the ELCR registers now being processed (except for IRQs 0,1,2 and 13).

Just improved the i430fx/i440fx/i450gx chipsets and i440fx on i450gx(which uses the i440fx settings instead of the i450gx ones) to have proper PCI IRQ mapping.
I've also implemented the PCI INTA# through INTD# handling in the PCI emulation itself, along with support to raise and lower it on either the 8259A PIC or APIC (both are supported, but not both can be mapped at the same time. Although the APIC mapping currently is unused by the emulated chipsets(they can only map PCI to legacy IR lines on the PIC)).

Then I've modified the PCI IDE device on all chipsets to support putting the IRQs in PCI native mode(the registers were already supported, but the IRQs were fixed so far). So now either or both IDE controllers (primary and/or secondary) can be put in PCI native mode, of course sharing the configured INTA#-INTD# pin (though the interrupt pin PCI register).

So the basic functionality of PCI devices is now fully emulated (IRQ and BARs).

Edit: OK. So after fixing some little bugs, the PCI IDE devices now run properly on the i440fx again (there was an issue with the command register, causing it to not respond properly).
Windows 95 boots fine, but it doesn't seem to put it into native PCI mode(it keeps it in legacy mode)? Of course that doesn't verify the PCI operation yet.
Also, the chipset's mapping for INTA#-INTD# is set to do nothing(80h)?

Just found a slight problem with the way the PCI chipset was raising and lowering PIC IRQ lines. Instead of raising and lowering the seperated PCI interrupt lines as it should, it would modify the ISA interrupt lines (for any legacy device) instead of using it's own PCI lines, which run in parallel with the legacy ones.