OSDev.org

I have looked all over for this but can’t find a spec of locations or how to probe devices. I see osdev has a sample of hello world in mips but the line status and transmitter are hard-coded with a note about it possibly being different on other devices. All the samples I can find of keyboard input are for SPIM or mars (both simulators) and are also hard-coded magic numbers with no explanation.

I want to start with a small kernel that can work on an A mips 1 (R2xx or R3xx) processors with keyboard and terminal display. I want to provide a blocking call and a non-blocking interrupts based version. I am starting here because my real project is a mips simulator that I would like to eventually be able to run large oses on and I will build more into the kernel if I need it. Once I have that I will go to simulating disk and vga and/or newer versions of MIPS, but I think those may have better documentation

Any help would be greatly appreciated

There’s no standard MIPS PC like x86 PC. It’s SoC/board/emulator-specific.

alexfru wrote:There’s no standard MIPS PC like x86 PC. It’s SoC/board/emulator-specific.

Thanks for the quick reply. How does the kernel know where devices are then? Also, just wondering how you know this or rather what I could have searched to find that out?

Thatguyme wrote:

alexfru wrote:There’s no standard MIPS PC like x86 PC. It’s SoC/board/emulator-specific.

How does the kernel know where devices are then?

It depends. If device addresses are fixed, they can be hard-coded in the kernel/drivers. If the devices are attached to some flexible bus like PCI(e), I'd expect a standard discovery/enumeration procedure for that bus.

Thatguyme wrote:Also, just wondering how you know this or rather what I could have searched to find that out?

It's enough to know that there exist a lot of different MIPS CPUs.

Microchip makes PIC32 microcontrollers, which are MIPS32 CPUs with a variety of on-chip connectivity options (ports, ADCs/DACs, etc), most are quite limited in terms of performance (in-order execution, single core, speeds no more than a few hundreds of MHz) and memory (little on-chip memory, no options to connect external RAMs), which can't run modern Linux, but can run something smaller like old BSD.

Ingenic makes XBurst CPUs, which are quite powerful (in-order execution, dual-core, runs at 1.2GHz) and can run Linux and Android (most needed things are on-chip, there's a board (now discontinued) with this CPU, CI20, which has very few other things on it and just needs a keyboard/mouse and a display connected and it can be a complete Linux or Android computer).

MediaTek makes a variant of MIPS24KEc, also a very decent CPU that runs at 580MHz and can run Linux or OpenWrt. There's a cheap LinkIt Smart 7688 with lots of connectivity options for IoT.

Baikal Electronics makes Baikal-T1 CPUs, which are MIPS32 CPUs with very good performance (dual-core, out-of-order execution, SIMD instructions, speeds up to 1.2GHz) and can be made into a good PC (the CPU has on-chip support for PCIe, 1/10Gb ethernet, SATA, USB).

There are lots of MIPS32 and MIPS64 chips in consumer routers and other network equipment.
There are MIPS chips in use for computer vision (see MobilEye).

Most of these CPUs are compatible at the instruction level and differ in how they deal with low-level system things (memory, interrupts, etc) and devices. A lot of MIPS customers customize the IP for their own needs. Same with ARM.

I know because I happen to be working for MIPS.

There is also Loongson computers (by Lemote I guess), their newest versions are yet more PC-ish - mini-ITX form factor, multicore, PCIe, SATA, (SO)DIMM slots. And that is mips64. Costs ~400$.

there's a board (now discontinued) with this CPU, CI20

Is it? I thought they are just in transition and didn't establsih an online store yet. For sure, there is some linux "mainline" effort. For example, they started to use Device Trees for the hardware configuration. The initial BSP don't use this. This is right about the author's question. You take TRM and decide how you want to represent a static platform configuration.
- your own tables or whatever data structure.
- your own hand-made ACPI tables.
- hand made Device Tree
- or just C headers with loads of funny names like this HDMI_PHY_I2CM_SS_SCL_LCNT_0_ADDR

The on SoC core controllers are memory mapped. On CI20, they are mapped the way that addresses fit with kseg1 VAS, so you don't need even any mapping. What I mean? For example the base address (system address) of the MSC0 - the first of three MMC/SD/CE-SATA controllers is 13450000. In order to write into its register, all you need is write/read to (b3450000 + RegisterOffset). Well, I guess you know about what kseg0/1 are.

alexfru wrote:

Thatguyme wrote:

alexfru wrote:There’s no standard MIPS PC like x86 PC. It’s SoC/board/emulator-specific.

How does the kernel know where devices are then?

It depends. If device addresses are fixed, they can be hard-coded in the kernel/drivers. If the devices are attached to some flexible bus like PCI(e), I'd expect a standard discovery/enumeration procedure for that bus.

Now, just to clarify this point: what Alex said about MIPS is just as true about any computer hardware, including the PC class x86 systems; the difference with those is that PCs are all designed to be backwards-compatible with existing PC software, and have certain features which have to present the a standardized set of hardware and firmware interfaces, most notably the BIOS (whether Legacy or UEFI).

The very fact that a general term (Basic Input/Output System) long predating the PC is now seen as specifically referring to the PC Legacy BIOS, to the point that many will argue that it is the only true meaning of the term, underscores this (though the fact that UEFI isn't just a BIOS, and that a given UEFI implementation's internal BIOS is only really used by UEFI itself, does muddy the water a bit).

For all its faults and limitations, the PC Legacy BIOS, and specifically the fact that a clean-room re-implementation of it was possible and those making them withstood legal challenges (this was a big deal waaaay back in the mid-1980s), was more than anything the reason the PC class of systems succeeded - had IBM not lost control of the platform after Compaq's BIOS was ruled not to be infringing, the PC would probably be a historical footnote today. It is a unique aspect of the PC platform today that anyone with the funds and engineering team to do it can build a PC-compatible system, and set it up so that it can run Windows (and in most cases, any other PC OS) so long as they can modify an existing BIOS framework to talk to their specific hardware. There is a lot more to it than that, of course, but the BIOS, and the ability to re-implement it for a wide variety of x86-compatible CPUs and ISA/PCI/PCIe compatible bus configurations, was a major factor in the success of the platform. All of the existing standards for PC hardware and software built on this success.

The introduction of UEFI has expanded this a bit, as it isn't exclusively tied to the x86 and the common types of PC bus systems, but it is definitely heavily influenced by the PC BIOS. Since very few if any non-PC systems have implemented UEFI to date, it isn't really something you can expect to be present for a MIPS-based system.

Note that this also means that an x86-based system that doesn't have a BIOS or UEFI as it's firmware (or has a memory bus or peripheral buses that are drastically different from those common on PCs) cannot run PC software, at least not out of the box. This was a fairly common issue in the early 1980s, especially with some of the not-quite-PC compatibles such as the DEC Rainbow (often nicknamed the "DREC Painbow" for it's poor build quality and lack of actual PC compatibility) and the Olivetti/AT&T 6300 (which was actually pretty good hardware, when looked at in a vacuum) which ran versions of MS-DOS, but which were partly or wholly incompatible with off-the-shelf IBM PC programs and peripherals. This sort of thing mostly vanished by around 1986 or so, because, seriously, why put up with something as awful as the x86 if you don't get the main benefit of doing it, namely the huge PC-DOS (or later, Windows) software library?

But the take-away here is that you need to have the appropriate documentation for the hardware and firmware when writing an OS (or indeed anything that interfaces with said subsystems). The difference is that with PC class systems, the hardware manufacturers all copy IBM (or, after 1987 or so, each other), and stick to doing things that won't break compatibility in a way that a driver update won't fix. The ability to assume that the hardware works in one way across hundreds of different brands and models, over a span of three-going-on-four decades, is something unique to PCs.