Exploring Other Areas

[Nathan]

Hello,
I want to open a discussion to know why people today don't tend to build OSes for x86 and x64 platforms, but they forget that we have platforms as ARM, MIPS, PowerPC and m68k(the most used ones, but sure that have others, as 6502, but they aren't used so much today). And these platforms that really need to have OSes, because the normal ones(x86 and x64) are so much saturated, also it already have many very used ones(Windows, Linux, BeOS and Mac), then starting a OS today for it will be a very difficult task if you want to have real success as they have.

What I really want to make you think is this, why we tend to build for them? why we don't look to the others? And many other questions that pop-up on my head and I can't answer. I'm also opening a poll(peoples posts, as only moderators can open polls) to know who here on the community is interested on developing OSes for other architectures, who is already developing for them and who don't even think to change from the most used ones(x86 and x64) to another, and a flavour of irony, for that people that think that I need to stop thinking too much.

Think on This,
Nathan Paulino Campos

[Creature]

What I really want to make you think is this, why we tend to build for them? why we don't look to the others? And many other questions that pop-up on my head and I can't answer. I'm also opening a poll(peoples posts, as only moderators can open polls) to know who here on the community is interested on developing OSes for other architectures, who is already developing for them and who don't even think to change from the most used ones(x86 and x64) to another, and a flavour of irony, for that people that think that I need to stop thinking too much.

Think on This,
Nathan Paulino Campos

I think the main reason people go for x86/x64 is because there's simply a lot of information about it on the wiki. Practically all tutorials and articles we've written are about x86 or x64 (with some exceptions). It's probably also the easiest platform to test (almost any emulator can run it and PC's are AFAIK much more common than e.g. ARM-devices).

I agree with the fact that it's (practically) impossible to write an OS to the standards of the current mainstream operating systems, but remember that most people of this community don't want to compete, they simply want to learn, experiment and are interested in the subject.

[Benk]

For a hobby the reason is obvious everyone has one .. though i note Arm is comming up stronger now people have some consumable devices at hand.

[Nathan]

For a hobby the reason is obvious everyone has one .. though i note Arm is comming up stronger now people have some consumable devices at hand.

With this many devices coming up, this is a prosper world.

[tharkun]

The problem with architectures such as ARM, MIPS and PPC, isn't the lack of documentation, it's in fact the exact opposite, the sheer range of documentation and platforms. Most people get confused over where to start.

If you want to port your operating to another architecture, I personally recommend, for ARM, the Integrator-CP, the Versatile-PB or something like the Beagle Board. All of these have documentation online, have plenty of peripherals and two of them are emulatable by QEMU and the other is very cheap. For MIPS, I'm not sure, but I'd have a look a things such as homebrew on the PS2. For PPC, go with something such as PS3 (which as far as I am aware, can install other operating systems), or the old PPC Macs.
Another architecture, people might be interested in is SPARC, which is still AFAIK in current production by Sun Microsystems. It's mostly used in servers and quite expensive, but is emulated by QEMU. Sun does, or at least used to, sell SPARC workstations, these unfortunately were also expensive, you can probably buy them second hand from ebay.

The platforms listed above aren't the only ones - just my recommendations for those processors. There are hundreds more to choose from. This is one major problem with porting. The other major problem, is simply the porting itself. A lot of the architectures above are big endian, while the x86/x86-64 are both little endian, this can lead to problems with structure and data alignment whilst porting.
Take for example this piece of code:

Code: Select all

#include <stdio.h>

int main (int argc, char ** argv)
{
    int c;
    scanf ("%c", &c); /* Where does &c point to?? */
    printf ("%c\n", c); /* What get's printed?? */
    return 0;
}

This code will only work as expected on little endian architectures. This is because on little endian &c points to the LSB of c, this is the part that is used in the cast to char. However on big endian, &c will point to the MSB of c, causing bugs.

Oh and if anybody wants to look into porting to ARM, there's a barebones now on the wiki.

ARM Integrator-CP Bare Bones

[fronty]

Another architecture, people might be interested in is SPARC, which is still AFAIK in current production by Sun Microsystems. It's mostly used in servers and quite expensive, but is emulated by QEMU. Sun does, or at least used to, sell SPARC workstations, these unfortunately were also expensive, you can probably buy them second hand from ebay.

SPARC is my architecture of choice. I just love it.

Currently QEMU emulates usably sun4m (SPARC V8). It can boot linux and netbsd, openbsd failed last time I checked, older Solaris fails partly due to lacking obp. sun4u (SPARC V9) emulation is on its way but isn't close to usable.

Sun hasn't sold SPARC workstations for several years, in fact no one sells RISC workstations anymore. IBM was last to drop its line. You can buy new SPARC server from Oracle with something like 10 000-11 000. People sell their SPARC boxes for quite low prices on the net, if you can find someone living close to you you can get nice SPARC workstation for very low price.

Damn I don't have currently any SPARC boxes usable. Maybe I should play around a bit with QEMU.

[Owen]

A word of warning: The PS3 slim has never been able to install other operating systems, and with the April 1st firmware update, the ability to install on to the original models has also been removed.

(The reason? Two of them: Maintenance cost and piracy)

[rudimk]

The problem with architectures such as ARM, MIPS and PPC, isn't the lack of documentation, it's in fact the exact opposite, the sheer range of documentation and platforms. Most people get confused over where to start.

true. ARM, for instance, has more than a dozen implementations around. and while the base architecture's the same, the design of the board, the peripherals..they're quite different from each other.
plus, let's be honest. how many of us have seen...or even heard of a proper course on ARM/MIPS/PPC assembly in college or university? i mean, yeah...some places have incorporated MIPS assembly programming in their computer architecture courses. but seriously, that just isn't enough to teach you everything! everywhere i go, all i see, is "x86 Assembler" or "IBM PC Assembly".

but, out of all three, i'd say that IMHO, ARM's the easiest to grasp. something about it makes you learn the ins and outs of ARM assembly pretty quick

Oh and if anybody wants to look into porting to ARM, there's a barebones now on the wiki.

[url=http://wiki.osdev.org/ARM%20Integrator-CP%20Bare%20Bones]
ARM Integrator-CP Bare Bones[/url]

i read it a couple of days back. awesome
may the lord bless this kind soul

[cb88]

I would *really* like to see some tutorials about OSDEV on SPARC hardware I have quite a few 32bit machines.
2 SS2 (have linux on them haven't really booted them I plan to put netbsd on them or an LFSish Linux build)
1 SS5 70Mhz 144Mb ram CDROM its the coolest one IMO with the exception of the SS10 & SS20 which have smp
2 SS10 (40-60Mhz mbus modules... I plan on buying some ROSS modules to make on of my systems quad processor)
1 Ultra1 167Mhz seems to work runs redhat 5.2 iirc with KDE1 ... integrated CDROM

I also have a 19in sun and 21in sony 13w3 to complete the experience ... the 21in is probably going to get transplanted into a salvaged case as the working unit's case is cracked and the broken one doesn't sync (except on rare occasion under a blue moon) .

I have just standard cgsix framebuffers in these...


from what I understand [1] the place to start is the header file from BSD for the openboot prom
http://sup.netbsd.org/pub/NetBSD/NetBSD ... openprom.h

Which defines functions available directly from the prom for instance a built in printf()

If someone would be willing to work on writing a complete tutorial series for this hardware I would be willing to send them one of the sparcstation 2 systems for shipping cost (20lb I suppose) one I have has 16Mb ram and the other 32mb and half Gb SCSI disks in both the floppy drives I am not sure of they seem to work but in anycase netbooting would probably be the way to go since all SUN SPARC hardware can do it and it isn't too hard to setup given any old extra Linux box around to host the tftp and rarp server.

I would be willing to document setting up tftpand rarp but its already documented in many places for specific distros etc... I have been able to boot netbsd from tftp+rarp so its probably a good option.

As a side note even the SS2 would make a decent router with a couple cheap (nowadays) ethernet cards in it since it has 3 open sbus slots if you remove the framebuffer I don't think it can do 1Gb Ethernet however as the prom doesn't support it openbsd hints that it could be possible via a kernel fcode (prom language) interpreter though.

The reason I picked up these SPARC boxes is I just liked the overall design of the systems regardless their age and felt they would be good for learning about kernel and driver development at least more so than x86 with its hacked up memory addressing vs SPARC addressing which gives you the full address space immediately without any tricks. If someone wants to help me out I'd appreciate It I have lots of questions. By the way I am a computer engineering student in my senior year at UNC-Charlotte.

[1]http://www.cheesecake.org/sac/os-supp/

[fronty]

SPARC is a fine architecture. I haven't written anything low level in ages and I've forgotten all fishy low level details when writing only userland stuff for SPARC and low level stuff for x86 and haven't got anymore any kind of access to SUN hw, so currently I can't provide much to wiki. I will look if I can find my old hobby OS for SPARC from some old backup so I could upload it somewhere and post stuff based on it to wiki. (EDIT: Still not luck, I'll keep looking.)

I don't know what is current situation in SPARC V8, but if you want non-Solaris operating system on V9, your best choice is clearly OpenBSD.

[cb88]

@fronty actually its probably a split between netbsd and openbsd... netbsd has more or less working SMP in current (broken in 5.x) and framebuffer support is improving there AG-10E 2D acceleration and a few other rare cards. If I can find an AG-10E relatively cheap I would put 2 60Mhz supersparcs in the SS10 and use it as the xserver and window manager with the quad hypersparc SS10 as host for the client apps which should be acceptably fast.

openbsd I havn't tried yet though... I was hopeing to find a fujitsu AG-10E framebuffer to put in one of the SS10s but haven't seen any. a ZX would be too hot probably for the SS10 possibly not with only an Ethernet card and the SM61s. The SparcStation 2 I mentioned is acutally Sparc v7 I believe but that shouldn't matter for a basic kernel since its the lowest common denominator out of v7 v8 and v9.

If you can find your source for that hobby OS of yours that would probably be a great help... since I haven't really found anything that explains booting from the kernel perspective on SPARC

Long term I'd like to write an OS to demo/test LLVM SPARC code generation with LLVM integrated so after that is setup all programs would be jitted and cached and possibly rejitted in the background during idle. I realise that would also require learning LLVM and adding SPARC jit code to it as currently LLVM can generate SPARC code but not jit it.

Long Long term... I'd like to see Haiku ported to SPARC but like I said long term...most of the drivers could probably be ported from a BSD as haiku already uses network/wlan drivers from FreeBSD

[fronty]

Oh, didn't SS2 use SuperSPARCs and HyperSPARCs? I thought they were SPARC-V8. In fact I thought whole sun4c was SPARC-V8 as sun4m.

The problem with old hw may be finding docs for prom. For OBP you at least have standard.

If you want some source code to read about booting, I suggest SILO in addition to NetBSD and OpenBSD boot loaders.

[Ready4Dis]

Personally, I have more x86 computers than I do anything else. I do have other micro and dev boards, but none of them already have a network card, gpu, loads of ram, a hard drive, can boot from usb, mouse/keyboard interface, or a video interface. What's the point of writing an OS for a one off board you made? If that's your thing, go for it (I plan to port my OS to a custom made platform when 'done'), but most people find that it's much easier to write one for the x86/64 rather than develop an entire new platform (and lets face it, just because people program, doesn't mean they can interface hardware). Buying a pre-built dev platform is all fine and well, but that costs money, and most of us dev's don't have a ton to spare, so working with what we have kinda comes second nature, and all of us here have a computer I'm sure .

[cb88]

I'm pretty sure all the sun4c hardware was v7 .... I think one of the SS2's I have has an original 20Mhz chip and the other has an upgraded 40Mhz weitek powerup which is about twice as fast.

I guess I'll have to investigate silo then.... and how netbsd builds its kernel

[cb88]

@berkus SPARC is hardly dead if the European Space Agency is still buying LEONs and fujitsu sells them independently from Oracle/sun

Besides its kindof hard to kill a processor that is an IEEE standard MIPS has come back to life more than once and it isn't even a standard or free license/sell. Tilera being the latest MIPS reincarnation along with loongson.

SPARC IMO is more attractive in many real ways than MIPS so... I'm not sure why more companies don't jump on that. Personally I'd like to see a lot of things happen with sparc and who knows maybe they will...