OSDev.org

I seem to get nowhere with RDOS on my new portable PC.

The network cards (both the wireless and the wired) are propietary designs with no specifications.

AHCI. The OS comes preinstalled with AHCI enabled, which means I have no access to the disk since my AHCI-driver is not yet functional (I hope to complete that one though).

USB. There seems to be an EHCI-controller with no companion (UHCI/OHCI) controller. I wonder how this is supposed to work with older USB-devices?

The VESA/VBE is really broken. It anounces a protected mode interface, but one of the first things the entry point does is to load DS with CS, and then try to write via DS. That interface could not have been tested with anything. But it gets worse. If my code is patched to always use V86-mode, it is possible to retrieve available video-modes, but when video-modes are set in V86 mode, the code once more faults. On something. I have no idea why because the screen is also messed-up. And since there are no ways to make an ethernet-driver, I cannot hope to remote debug this issue either.

I really wonder how to fix these issues.

OTOH, it has a Intel CoreDuo processor, and I have no SMP issues with the machine. Seems like SMP support is rather stable right now (I've also run it a lot on a 4-core AMD Athlon).

I can well understand your problems. I have many computers and I can assure that BIOSes are made with a copy&paste from older motherboards, with all the issues you can imagine.
The VBE of all the eeepc is the demonstration of what I'm saying, but many services are still bugged (the memory map from my old laptop for example).
This is also why VBE3 aren't supported anywhere. -.-

rdos wrote:AHCI. The OS comes preinstalled with AHCI enabled, which means I have no access to the disk since my AHCI-driver is not yet functional (I hope to complete that one though).

You can disable AHCI mode in BIOS Setup when booting your OS. I reinstall Windows with this option to boot my OS without changing this option every time.

EHCI doesn't require companion controllers if the root hub supports rate matching, oddly enough I was just talking about this today.

As for the Ethernet/Wireless, lack of datasheets isn't exactly a "new" thing. But OpenBSD supports quite a few wireless chipsets, a lot of it was done by reverse engineering.

egos wrote:

rdos wrote:AHCI. The OS comes preinstalled with AHCI enabled, which means I have no access to the disk since my AHCI-driver is not yet functional (I hope to complete that one though).

You can disable AHCI mode in BIOS Setup when booting your OS. I reinstall Windows with this option to boot my OS without changing this option every time.

Yes, possible, but I want to update my disc-driver with something a little more modern than PIO-based IDE. For performance reasons, and because I don't want to have to disable AHCI in Windows in order to dual-boot RDOS. I'll probably even switch-over the controller to AHCI-mode if BIOS hands over the controller in IDE-mode when the controller obviously is AHCI-based. The AHCI specification documents how to do that.

Of the issues I have with my portable, this has priority one since it is hard to do debugging without disc-access.

In order to solve the video-mode issue, I suppose the only realistic solution is to provide remote debugging over a serial port. That, OTOH, would require an working EHCI-implementation since there are no real PC-style serial ports.

Another solution would be if there existed some USB-ethernet box with full documentation, but I doubt it.

Making some progress here. The AHCI driver is almost working, and I've contacted the NIC supplier (Marvell Yukon, 88E8057) and I think it would be possible to obtain the specification after I've signed an NDA, and used the company I work at as a reference.

Just curious, did you managed to get the touchpad working? I've tested my OS on one of these, and found that ps2 mouse initialization is broken too. I've initialized Z axis, it's reported okay, but still sending me 3 bytes, thus making packages misaligned. I've created a workaround, but it's not nice, I would preciate a clearer solution. It goes like this:
Timer irq increases a counter. If irq12 fires, I reset it. There's another counter that count packet bytes, and I have it reset after all bytes received (see my code at "ps2 mouse driver in asm" thread). If the timer counter is bigger than 5 when irq12 fires, I check whether the packet counter is zero. If not, I fallback to 3 bytes per packet, and reinitialize mouse variables. This way I loose the first mouse event, but afterwards it works fine. It's based on the assumption that timer irq fires only once or twice between mouse packet irqs.

I hadn't tested this before, but apparently it is broken on my machine as well. In my case, when I load the mouse-driver part, the keyboard stops working. Might be wrong number of bytes reported as you suggest. I would create a new driver that expects lesser bytes if I were you, rather than tweeking the PS/2 version.

I don't think I will bother trying to make it work, especially since I still haven't got the NDA for the network-chip. I'll probably give it to my son or daughter, and buy a new Compaq Presario CQ57 or similar, that I know works with RDOS. Or maybe a better one with more cores, if that is available. My stationary computer (self-built 4-core AMD Athlon) also works fully with RDOS after I mounted a PCI-network card (RTL8169-based), so then I will have two modern, working computers at home.

OK, so I have got rid of this machine, and now I have two other machines at my disposal. First, I have a brand-new AMD phenom with 6 cores, 2.8 GHz, AHCI (but set to legacy mode in order to be able to boot Windows XP). The first attempt to boot this machine with RDOS failed (it works in PIC-mode but not in APIC-mode). The other machine is a 2-core AMD Athlon. Both these machines have Realtek's gigabit ethernet controller, which I have a working driver for. Additionally, I also have access to a dual-core Intel Atom-based machine (a mini-PC). Makes for some fun testing.

The 6-core machine also has a UEFI BIOS.

I'll post the progress (and problems) here, just so nobody complains about spamming.

The 2-core AMD, which I couldn't make work a few years ago have some problems with the ordinary PIC, but works just fine with APIC. The disc (IDE) and network (RTL8168) works just fine. There is some bug in the video-mode switch code (it jumps to 0:0 in V86-mode). OTOH, with a working network-driver (and IDE disc), and this happening before the actual switch of the hardware, I think this is possible to solve.

The 6-core AMD probably has some problem with the ACPI-tables, as it locks-up with the ACPICA driver, and the APIC driver reboots the computer (could also be ACPI-related). I wonder if this is related to the machine having 4GB memory, and 1GB of video memory? Anyway, this is probably also possible to solve.

I've come a little further on the 6-core AMD. The ACPI driver now works, and I can collect the information from the APIC table. However, even with the correct base address for the local APIC, the computer still reboots when additional cores are started. Even if no cores are started, the APIC cannot be enabled because then IRQs no longer work.

I didn't get the specifications (or a NDA) from Marvell, but I just found a pdf with the complete documentation for the programming interface for Marvell 88E50xx series ethernet controlllers. I'll do the driver after all. If somebody else needs the documentation, pm me.

The bad thing is that the specification is more complex than for comparable controllers, and contains lots of junk you are not expected to change.

rdos wrote:The bad thing is that the specification is more complex than for comparable controllers, and contains lots of junk you are not expected to change.

We need a "open specification fat-trimming committee" that rewrites spec sheets and programming interface documentation to be more casual-implementer-friendly.

Not only that, but the document is classified as confidential and proprietary. In order to get it you normally need to prove that you have a business that will sell 1000s of network chips, and that you cannot use the ready-made drivers for all platforms Marvell found worth-while supporting. It was just pure luck that I found it in the download section of some site. I bet few, if any, lesser-known OSes support their chips.

In other words, somebody that signed their NDA has violated the rules and put the specification at a place where Google could find it.

Yesterday I did manual changes to various operational registers in the Marvell controller, and actually was able to enable the MAC and PHY. Today, I cannot reproduce what I did with code, and every time I try to enable the MAC or PHY, the computer "freezes".

I wonder if it really is possible to understand the complex operation of this controller just be reading a pdf of a particular version. There might be something else that I'm missing, or possibly my controller doesn't have the same register mappings? I think there are up to 10 different units in the controller that might need to be taken out of RESET, and put into operational mode, and most of these units are poorly documented.

Edit: Just found out that the LinkControlReg is very important, which caused the crash. It must be changed before any MAC related operations are attempted.

Current status is that the BMU queues (RX, TX and Status) are setup, the FIFOs are enabled, the MAC is enabled, and I can read-out link state. At least something.