UniPCemu has a serial modem on the COM2(port base 2F8) port. The COM1 port has a serial mouse connected when the PS/2 mouse isn't available(on all Compaq Deskpro 386 and earlier architectures).
The i430fx/i440fx has a dummy port there, without any device plugged in.

Do you know how to make Minix use said COM2 serial modem dialling in(which establishes a TCP connection to telnet when it's answered using the AT command)? Telnet should be able to dial it.
The main issue is telling Minix to use the COM2 serial modem in autoanswer mode?
Any idea how to pass it these boot parameters?
I have no idea how things like the "edit" command actually works, what parameters to pass through it etc. ?
https://wiki.minix3.org/doku.php?id=usersguid … x3_boot_options

OK, interesting. No I don't know about that dialing stuff. You can tell the kernel which port it should use and the baud rate, that's about it.

The easiest way to use the boot parameters is via the Minix 3.3.0 ISO startup menu, select 3 and press Enter, then you can just type the additional parameters. When you're done press Enter.
But yeah, I don't know what would be good combo here for UniPCemu...
There is also a .cfg file in the iso that is used for default values.
The startup messages are written to /var/log/messages, if that could be accessed somehow (EDIT: Probably wouldn't help anyway - I think this is the job of syslogd and that isn't started until the kernel startup is done).

EDIT: In that param list there is also this: debug_fkeys=1
If that is set, Shift+F5 gives a list of keys that give more information.

Tried typing the additional parameters directly(adjusting the cttytype=0 to cttytype=1 (since it needs COM2 instead of COM1)).

Don't know if it'll be able to handle the dialing in from the serial modem instead of direct connection, though.
It might need to be added into UniPCemu(make the modem a passthrough without commands, but with autoanswer(no output for rining or hangup, ignoring incoming commands and escapes) automatically enabled and when dialed to without any special stuff)?

Yeah, at least the way qemu does it is sort of passthrough too (it creates a telnet server that you then connect to, via TCP).

I just added a new option to UniPCemu's modem emulation, where it will be in autoanswer mode without delay during rings(with the messages of ringing and disconnecting not being sent). It also will start the TCP server when nothing is connected. Once a client (telnet or another) connects, it's stopping the TCP server, preventing new clients from connecting until the client disconnects (just as it does with a normal ringing of the modem).
Of course, commands and escapes to the serial modem are ignored completely(although command mode inputs will all be discarded).

I don't see the OS sending anything at all to the serial modem at all, even though it's connected to the telnet client?
Edit: Does it require something non-modem on the modem status to appear in this case?

superfury wrote on 2020-12-20, 16:08:

I just added a new option to UniPCemu's modem emulation, where it will be in autoanswer mode without delay during rings(with the […]
Show full quote

I just added a new option to UniPCemu's modem emulation, where it will be in autoanswer mode without delay during rings(with the messages of ringing and disconnecting not being sent). It also will start the TCP server when nothing is connected. Once a client (telnet or another) connects, it's stopping the TCP server, preventing new clients from connecting until the client disconnects (just as it does with a normal ringing of the modem).
Of course, commands and escapes to the serial modem are ignored completely(although command mode inputs will all be discarded).

I don't see the OS sending anything at all to the serial modem at all, even though it's connected to the telnet client?
Edit: Does it require something non-modem on the modem status to appear in this case?

That was fast, your nick is well earned 😁
Hmm, I'm not very well versed to comment on this, but you should definitely see *something*
(verbose=2 gives more wall of text of course).

I've just modified the status register reporting by the modem to behave as follows in the new nullmodem mode:
- CTS is set when the TCP connection can send data to the other side(connected and buffer has room).
- Ring behaves normally(though never seem as it's immediately acnowledged by the connection manager).
- DTR and DCD are set when connected, otherwise cleared.

It was a simple improvement to add to the already existing modem emulation, which is why it was so fast to implement. I just added some ignoring on various handling of the modem(command mode ouput being ignored, slight adjusting to the TCP acnowledging logic(to ignore DTR of the UART and keep connected status into account) and suppress the two kinds of messages sent from the modem(the RING message and the connect/disconnect messages).

Edit: Just fixed some more issues with the new mode. It will now properly ignore the DTR/RTS line effects(the ones for PnP auto detection and DTR off response disconnecting the client).
RTS is now honoured and DTR is now ignored completely in nullmodem mode.

superfury wrote on 2020-12-20, 14:48:

cttytype=1 (since it needs COM2 instead of COM1)).

Typo in the post, or the command line? This should be cttyline=1
That would explain why you saw nothing...

It's a typo in the post.

I simply modified the BOOT.CFG line to say this:

1menu=Regular MINIX 3:multiboot /kernel bootcd=1 cdproberoot=1 rootdevname=ram disable=inet cttyline=1 cttybaud=115200 verbose=2

Yeah that should work.

Well, nothing is sent over the serial line at all? The modem status register reports all bits set, except the ring indicator (because it's autoanswering without delay in this case. also not sending the RING messages to the OS).

This is what's in the CD-ROM image (version 3.3.0, but adjusted to add debugging) BOOT.CFG file:

1banner=Welcome to the MINIX 3 installation CD
2banner================================================================================
3banner=
4menu=Regular MINIX 3:multiboot /kernel bootcd=1 cdproberoot=1 rootdevname=ram disable=inet cttyline=1 cttybaud=115200 verbose=2
5menu=Regular MINIX 3 (with AHCI):multiboot /kernel bootcd=1 cdproberoot=1 rootdevname=ram disable=inet ahci=yes
6menu=Edit menu option:edit
7menu=Drop to boot prompt:prompt
8clear=1
9timeout=10
10default=1
11load=/mod01_ds
12load=/mod02_rs
13load=/mod03_pm
14load=/mod04_sched
15load=/mod05_vfs
16load=/mod06_memory
17load=/mod07_tty
18load=/mod08_mfs
19load=/mod09_vm
20load=/mod10_pfs
21load=/mod11_init
22# This space intentionally left blank - leave to appease bootloader!
23# This space intentionally left blank - leave to appease bootloader!
24# This space intentionally left blank - leave to appease bootloader!
25# This space intentionally left blank - leave to appease bootloader!
26# This space intentionally left blank - leave to appease bootloader!
27# This space intentionally left blank - leave to appease bootloader!
28# This space intentionally left blank - leave to appease bootloader!
29# This space intentionally left blank - leave to appease bootloader!
30# This space intentionally left blank - leave to appease bootloader!
31# This space intentionally left blank - leave to appease bootloader!
32# This space intentionally left blank - leave to appease bootloader!
33# This space intentionally left blank - leave to appease bootloader!
34# This space intentionally left blank - leave to appease bootloader!
35# This space intentionally left blank - leave to appease bootloader!
36# This space intentionally left blank - leave to appease bootloader!
37# This space intentionally left blank - leave to appease bootloader!
38# This space intentionally left blank - leave to appease bootloader!
39# This space intentionally left blank - leave to appease bootloader!

That should be alright, shouldn't it? It doesn't seem to have any effect, as nothing is done with the UART?
It does give a ISO9660 loading error before loading each of the modules, though.

Yep seems correct to me. EDIT: Also checked with qemu, modifying BOOT.CFG seems to work (used the first serial port though).

Just looked at what Minix does when booting(after loading the various modules).

I see it writing the Line Control register, followed by both DLAB registers(low and high), then the fault seems to happen?

So it seems to be https://github.com/Stichting-MINIX-Research-F … 86/rs232.c#L428, which is called from https://github.com/Stichting-MINIX-Research-F … 86/rs232.c#L501 .
Since the write to the Interrupt Enable Register isn't reached, it would mean that the page fault seems to happen right there?

I'd assume that interrupts are disabled at this point, so there might be an invalid jump at that point, when returning from the function?

I see Line Control register being written, then DLAB low, DLAB high and finally Line Control register again, after which the Page Fault occurs that crashes the OS.
So it's probably rs_config executing right there. There's a page fault before it returns, so that's a invalid RET?
The issue happens within the rs232 init itself, so obviously it can't write anything to the connection yet!

Heh, that certainly sounds like a plausible explanation for the mute connection. I can't imagine what else could it be within that code portion.

The boot process says the following, after the boot option(Option 1 will be chosen in 0 seconds):

113033+6035+55425+158064+397140=0x9bb7c
2WARNING: couldn't open cd9660 (//cd9660/cd9660.kmod)
3Loading /mod_01_ds

Then continues on normally(through to the last mod (mod11_init) file, after which the UART crash occurs).

What I see:
1. Write line control register value 0x83 at 0008:f041f959
2. Write DLAB low value 0x01 at same address.
3. Write DLAB high value 0x00 at same address.
4. Write line control register value 0x03 at same address.
Then a slight delay, after which the page fault exception displays. During this delay, I've simply stopped logging:

At 0008:f041acd2, it looks like it's back at the function's code?
Edit: 0008:f041ace5 still said function. For the DLAB high value? Leaving for the OS call at 0008:f041acec.
Edit: Then the finishing LCR at 0008:f041ad00.
It then reaches 0008:f041ad05. That's probably reading the status port and adding CTS, according to the source code( https://github.com/Stichting-MINIX-Research-F … 86/rs232.c#L435 )?
The return point is f041ad0a.
Edit: Hmmmm... It should be here (fixed to be at proper R3.3.0 version): https://github.com/Stichting-MINIX-Research-F … 86/rs232.c#L416
But that doesn't match the code that's being executed when returning from the LCR write at all? It's supposed to perform a port read from https://github.com/Stichting-MINIX-Research-F … 86/rs232.c#L204 , but it doesn't seem to call that instruction at all?

That debug log is kinda hard to follow but I think you got it right. Here's a trick you could try:

Get yourself one of these:
https://github.com/radareorg/cutter

They have Ghidra decompilation now, so while this really helps with any kind of binary, it's especially helpful if the code was written in C.
You can use that to examine KERNEL, makes it a bit easier to see what's going on.
(Of course you can use original Ghidra and maybe IDA too in a similar manner)

The latter part of fcn.f0427260() seems familiar...

Looked around a bit. The kernel starts in a simple way, described at https://wiki.minix3.org/doku.php?id=developer … guide:earlyboot
So it's probably indeed the kernel's init somewhere?

superfury wrote on 2020-12-21, 19:18:

Looked around a bit. The kernel starts in a simple way, described at https://wiki.minix3.org/doku.php?id=developer … guide:earlyboot
So it's probably indeed the kernel's init somewhere?

It could well be an invalid RET as you suggested, but I don't know what could cause such a thing...have you seen things of that sort a lot?
Linux/NetBSD testing could provide more insight. I don't know if they share init code with each other, probably not much.

Running the cutter app indeed reveals the fn.f041ac50 function, where the sequence ends up being in (including the same addresses). And what do I see immediately after said code?

10xf041ad00      call fcn.f041f950
20xf041ad05      call fcn.f041fa60
30xf041ad0a      cmp dword [0xf048c854], 0
40xf041ad14      je 0xf041ad2b
50xf041ad16      cmp dword [0xf048b394], 0
60xf041ad20      jle 0xf041ad49
70xf041ad22      mov dword [esp], str.APIC_disabled__using_legacy_PIC ; 0xf04361a6
80xf041ad29      jmp 0xf041ad44
90xf041ad2b      call fcn.f0420c20
100xf041ad30      test eax, eax
110xf041ad32      jne 0xf041ad49
120xf041ad34      mov eax, dword [0xf048b394]
130xf041ad39      test eax, eax
140xf041ad3b      jle 0xf041ad49
150xf041ad3d      mov dword [esp], str.APIC_not_present__using_legacy_PIC ; 0xf04361c7

So it's indeed that part of code that's executing! The intialization of the APIC that's running? So it's the init code of the kernel!
So f041ad22 is actually https://github.com/Stichting-MINIX-Research-F … h_system.c#L272 !
So looking at what it's doing... It's actually acpi_init executing!!!