Dear Bill,
I've had similar woes with multiple NIC's in DOS, IIRC that was with
Intel chips... but could be modern Realtek, I don't know...
This problem pops up on me every once in a while, but hardly ever
anymore nowadays, as I don't PXEboot into DOS very often lately.
Unless you need both the NIC's, just disable one in the board's BIOS
SETUP - if available in your BIOS, which I don't know, as a quick
google search hasn't revealed a full user's guide. I've seen a few
screenshots of a fairly generic AMI APTIO which would be promising.
Hmm... the ZIMA has an Apollo Lake ATOM. Interesting. One of the last
generations of x86 hardware to still have a legacy BIOS CSM (ability
to run DOS on bare metal).
Note that the native host interface of the RTL8168 is PCI-e, not PCI.
Thus, the native IRQ delivery mechanism is message-signaled, and the
power-up default configuration is to emulate the PCI "wire braid"
IRQ's using messages called INTx (INTA...INTD). And, in this mode,
the RTL8168 produces strictly INTA. The x86 chipset (ATOM SoC) can
then "swizzle" or map that virtual wire to various GSI inputs of its
interrupt controller - which contains a backward-compatible IO/APIC,
and during a legacy BIOS boot, also backward-compatible with an i8259
AT PIC.
Only if you boot a higher OS (Linux/Windows), its native driver will
re-configure the NIC to use proper modern end-to-end MSI or MSI-X,
completely circumventing the legacy "wired topology" interrupt
controllers.
I've seen other hardware (completely unrelated to ZIMA, and a
different ATOM platform) that had the legacy-compatible virtual wire
INTx IRQ's misconfigured for its PCI-e slots. Which in my case turned
out problematic with some PCI-e UART's, whose drivers for Windows and
Linux did not use MSI. A good way to get onto this diagnosis was to
boot Linux with pci=nomsi . You'd get a defunct PCI-e device, with a
spurious IRQ (actual number) reported by Linux if you tried to use
the affected PCI-e device (so an interrupt got triggered).
Note that in Linux on these ATOM platforms, you have the luxury of an
IO/APIC, so you get the "virtual wire" IRQ's (GSI's) from PCI(-e)
routed to IRQ's 16-23 (decimal).
Whereas in your case in DOS, the additional problem is that all IRQ
inputs, including those from PCI/PCI-e, will need to be routed to
shared IRQ's in the range of say 3-15 (decimal). There will be
massive IRQ sharing. Which generally doesn't work very well in DOS,
and it's not (necessarily) the software driver's fault.
Unfortunately, for the PCI and PCI-e, you generally cannot affect the
IRQ routing/mapping. The BIOS does that for you, the driver in DOS
learns the supposedly assigned IRQ number from the PCI config space:
either via the PCI BIOS, or by direct access. I've never tried, but
very theoretically, if this was your suspicion (or a problem
pinpointed properly in Linux), you could try fiddling with the PCI
config space in the hardware, change the byte at PCI config space
offset 0x3C if memory serves (the INT line) and hopefully the Realtek
DOS driver would then pick it up... Err I don't know any generic tool
for DOS to manipulate the PCI config space. Which may also be locked
by the end of the POST...
All in all, from various perspectives, running Linux on the Zimaboard
bare metal, and QEMU-KVM on top, with DOS in a VM, sounds like an
appealing alternative option. Gives you additional comfort. And the
Apollo Lake is a fairly nifty CPU for virtualization - it can do e.g.
VT-d, with the IOMMU domains being quite reasonably granular. Then
again, VT-d (PCI device passthrough) probably wouldn't solve your
problem with a misrouted legacy IRQ... better have the NIC's run MSI
courtesy of Linux native drivers, and use a virtualized TAP device in
the guest VM for DOS.
Apart from QEMU-KVM, DOSEMU used to be another option - haven't tried
in a long while, and there has been a major revamp of DOSEMU a few
years ago. In the old days, DOSEMU was a relatively "thin" shim on
top of Linux, passing through as much of bare metal as possible.
Modern DOSEMU contains a thicker emulation, on top of devices that
are not very legacy-compatible anymore.
Frank
Date sent: Fri, 28 Feb 2025 17:40:38 -0600
To: freedos-user@lists.sourceforge.net
Subject: [Freedos-user] trying Zimaboard w/ Realtek 8168 NICs, no luck
From: Bill Allen via Freedos-user <freedos-user@lists.sourceforge.net>
Send reply to: "Discussion and general questions about FreeDOS."
<freedos-user@lists.sourceforge.net>
Copies to: Bill Allen <walle...@gmail.com>
>
> Greetings everyone! It may be that I have undertaken a futile
> endeavor, but I have been trying to get a Zimaboard with dual Realtek
> 8168 NICs working on FreeDOS. I must say that for an ancient IT guy,
> this has been a blast from the past having to go back to the days of
> loading up ODI packet drivers. However, I am just about to give up. I
> load up in the following sequence and this much at least works, or
> seems to.
>
> LSL
> RTGHODI.COM (asks me to select which of the two cards it finds, to I
> tell it the one the network cable is plugged into, NIC 1)
> ODIPKT.COM 0 96
>
> No errors at this point and it seems I have successfully loaded the
> packet driver into memory. The load up seemed happy enough with the
> settings in the NET.CFG. (It took a lot of work to get all the files
> and information together to get this far! LOL)
>
> After that, I try for DHCP.EXE from the mTCP distribution and get the
> following: Init: could not set up packet driver Could not initialize
> TCP/IP stack And then a message from FDNET.BAT (I think) that the
> Network is unreachable/unavailable, obviously as a result of the
> TCP/IP stack not being initialized.
>
> Am I pursuing an exercise in futility trying to get DOS networking
> going with what I presume to be very modern NICs? If so, not a huge
> loss but I feel like I am so very close.
>
> By the way, I am running FreeDOS 1.4-r2 with the very recent mTCP that
> is included. Everything networking with mTCP does work perfectly with
> the same in a Virtualbox setup.
>
> If y'all have read this far, thanks very much for your time!
>
> Best Regards,
> Bill
>
>
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
