OSDev.org

Between the second half of January and earlier this month, these 2 new SBC's have been up for grabs. I really want to get one, but I'm a bit torn in regards to the specs:

C120

• Dual-core 1.2GHz MIPS IV cpu (labelled as 32-bit little-endian on the elinux wiki, but anyone who's read the user manuals knows they can switch between big and little endian and have a 64-bit mode); w/ 512K shared L2 cache, 32kI + 32kD per core
• PowerVR SGX540 gpu
• 1GiB DDR3 RAM
• 8GiB internal flash memory (which it can be booted from)
• Built-in 802.11 b/g/n Wi-Fi and Bluetooth 4.0
• Built-in RTC
• Full-size SD card slot (which it can be booted from)
• 2 USB ports
• Price of $65

Pi2B+

• Quad-core 900MHz ARM Cortex-A7 cpu w/ 1MiB L2 cache
• Broadcom VideoCore IV @ 250 MHz (24 GFLOPS w/ FP16)
• 1GiB LPDDR2 RAM
• Half-size SD card slot (which it can be booted from)
• 4 USB ports
• Prices of $35 (though after having to buy extra stuff like an external RTC, BT+Wi-Fi chip, and extra memory storage to put it on par with the C120 in other areas, it'll probably break even with the C120 at $65 or more)

Generally, the Pi2B+ has more cpu cores, but has a slower processor and RAM. Additionally there's the matter of the gpu. I managed to find these specs regarding the SGX540, but it turns out there are actually 6 variations of it. The least powerful chip (Exynos 3110) runs wimpily at 200MHz (3.2 GFLOPS), but the most powerful chip (RK3168) runs at 600MHz (9.6 GFLOPS). With a gap that big, I'm assuming that these are likely FP32; meaning the SGX540 could be spanking the Pi2B+'s VideoCore. The SGX540 also apparently supports a few more codecs than the VideoCore.


Personally, I'm biased towards the C120 because I'm a huge fan of IRIX workstations. Which do you think is more powerful, and which would you be more interested in as a developer?

The question is what do you want to do with such a board?

alexfru wrote:The question is what do you want to do with such a board?

Generally, just hobby embedded OS development. In the case of the C120, I have a lot of confidential SGI software on my mediafire that would be cool to see if I could get working.

Or you could contribute to smaller and more challenging projects like RetroBSD or LiteBSD. All run on MIPS boards. Or even go 8-bit: FUZIX.

alexfru wrote:Or you could contribute to smaller and more challenging projects like RetroBSD or LiteBSD. All run on MIPS boards. Or even go 8-bit: FUZIX.

Seems like even more incentive to get a C120

The only thing that I don't like is that there are no cases for it yet. I could probably pay to have one 3d-printed though.

Black Swift will have a case.

Or you can have a GCW-Zero: Open Source Gaming Handheld.

These days you can find interesting boards or devices for a variety of uses. And those aren't necessarily berry pies or a-durians.

SoulofDeity wrote:C120

• Dual-core 1.2GHz MIPS IV cpu (labelled as 32-bit little-endian on the elinux wiki, but anyone who's read the user manuals knows they can switch between big and little endian and have a 64-bit mode); w/ 512K shared L2 cache, 32kI + 32kD per core

This is only a MIPS32 SoC, it doesn't support the 64-bit MIPS ISA.

MIPS may architecturally be bi-endian, but it is often only usable in order the selected by the SoC or board firmware.. proprietary Linux drivers for the PowerVR GPU are probably little-endian only.

(This means you probably won't be able to run SGI software, which may be 64-bit and big-endian)

Brynet-Inc wrote:

SoulofDeity wrote:C120

• Dual-core 1.2GHz MIPS IV cpu (labelled as 32-bit little-endian on the elinux wiki, but anyone who's read the user manuals knows they can switch between big and little endian and have a 64-bit mode); w/ 512K shared L2 cache, 32kI + 32kD per core

This is only a MIPS32 SoC, it doesn't support the 64-bit MIPS ISA.

So? Not everything needs to be 64-bit.

Brynet-Inc wrote:MIPS may architecturally be bi-endian, but it is often only usable in order the selected by the SoC or board firmware.. proprietary Linux drivers for the PowerVR GPU are probably little-endian only.

(This means you probably won't be able to run SGI software, which may be 64-bit and big-endian)

Most likely the MIPS CPU is configured as little-endian on the CI20 board.

alexfru wrote:

Brynet-Inc wrote:

SoulofDeity wrote:C120

• Dual-core 1.2GHz MIPS IV cpu (labelled as 32-bit little-endian on the elinux wiki, but anyone who's read the user manuals knows they can switch between big and little endian and have a 64-bit mode); w/ 512K shared L2 cache, 32kI + 32kD per core

This is only a MIPS32 SoC, it doesn't support the 64-bit MIPS ISA.

So? Not everything needs to be 64-bit.

Brynet-Inc wrote:MIPS may architecturally be bi-endian, but it is often only usable in order the selected by the SoC or board firmware.. proprietary Linux drivers for the PowerVR GPU are probably little-endian only.

(This means you probably won't be able to run SGI software, which may be 64-bit and big-endian)

Most likely the MIPS CPU is configured as little-endian on the CI20 board.

You didn't read my post properly, try again.

Was looking at the specs, and it appears as though the C120 is actually about 4-times as powerful as the most powerful IRIX workstation. On another note, just something I happened to realize:



There is no /boot, /home, /root, /run, /srv, or /sys on the filing system. Now, I know that /home and /run are relatively new additions, but the other ones kind of surprised me.

SoulofDeity wrote:There is no /boot, /home, /root, /run, /srv, or /sys on the filing system. Now, I know that /home and /run are relatively new additions, but the other ones kind of surprised me.

To have a dedicated boot fs is quite commonplace. The IRIX systems I have used IIRC had some relatively strange (to me) name and/or place for user home directories, probably something under usr, in extreme case something esoteric like /var/export/users. A root user's home directory IMO is mostly unneeded on both servers and workstations, so why include it. /var/run probably exists and handles the original job and subset of tasks of the new complete Linuxism /run. I've treated /srv as newish linuxism (at least newer than the hideous /var/www for web server data ), but I guess I've just been in my own kind of bubble too long to have seen or to remember seen it in active use earlier and in other kinds of systems. All in all, I think that's nothing unexpectable from a SysV derivative I'm unfamiliar with probably as much I can be unfamiliar with such system.

fronty wrote:...in extreme case something esoteric like /var/export/users.

That's rather interesting... I think a lot of the confusion regarding the /usr directory was caused by people simply throwing everything in it to share it among users. One of the problems caused by lack of standardization at the time.

fronty wrote:A root user's home directory IMO is mostly unneeded on both servers and workstations, so why include it.

Also desktops for the most part. At least, atm, there's nothing occupying my root directory. Maybe it has it's roots in the way that people set up networks?

fronty wrote: /var/run probably exists and handles the original job and subset of tasks of the new complete Linuxism /run. I've treated /srv as newish linuxism (at least newer than the hideous /var/www for web server data ), but I guess I've just been in my own kind of bubble too long to have seen or to remember seen it in active use earlier and in other kinds of systems.

Yeah, on my system /var/run maps to /run. This is one of the things I had talked about before where people move stuff around for nonsensical reasons. I've read a few /srv vs /var/www threads in the past, though I didn't know this was specific to Linux. The real thing that boggled my mind was the lack of a /sys directory.


EDIT:
On a side note, I just read here that there also didn't used to be /opt or /sbin directories. /opt was created to keep packages separate from the system when BSD and System V merged. The /sbin directory, thought to mean 'system binaries', actually meant 'static binaries'. The idea being that they were statically linked and didn't require /lib to be mounted in order to run. Linux parts from this concept, introducing added complexity and confusion.

EDIT#2:

spitfire wrote:home directories iirc, lived in /u (/usr these days)

OMG. Suddently, the old joke, "never talk about the /b" makes sense to me. lol. "Never talk about the binaries"

SoulofDeity wrote:That's rather interesting... I think a lot of the confusion regarding the /usr directory was caused by people simply throwing everything in it to share it among users. One of the problems caused by lack of standardization at the time.

I don't see any major problems in that with modern-y Unixes, say systems after sysIII. Okay, BSD derivatives were BSD derivatives and AT&T derivatives were AT&T derivatives and so on, but problems with /usr organization? I see only some minor problems. And if we're looking at the current situation, the "normal system" works well, both in one machine setups and network mounting, even in higher and higher pile of linuxisms they create, because they don't have to care about outside universe.

Also desktops for the most part. At least, atm, there's nothing occupying my root directory. Maybe it has it's roots in the way that people set up networks?

Well, yes, also desktops. I wasn't thinking of them, because we were talking a dead UNIX system. I would just guess that /root is relic from the time when messing around with your department's UNIX machine's root account, you didn't have to ridiculously paranoid about anything and just dumping stuff in root's home directory was just convenience for lazy people.

Yeah, on my system /var/run maps to /run. This is one of the things I had talked about before where people move stuff around for nonsensical reasons. I've read a few /srv vs /var/www threads in the past, though I didn't know this was specific to Linux. The real thing that boggled my mind was the lack of a /sys directory.

Oh, I skipped one. What kind of /sys do you want? Linux 2.6 sysfs? Don't expect it. Some milder version of that idea? Not surprised, more likely ugly system calls. Symlink to kernel binaries? Not surprised. Symlink to system sources? Don't expect in a commercial UNiX you grabbed, even if you got it from your uni.

fronty wrote:Oh, I skipped one. What kind of /sys do you want? Linux 2.6 sysfs? Don't expect it. Some milder version of that idea? Not surprised, more likely ugly system calls. Symlink to kernel binaries? Not surprised. Symlink to system sources? Don't expect in a commercial UNiX you grabbed, even if you got it from your uni.

So I'm guessing that /sys is for miscellaneous kernel-specific files... Not sure why they didn't just use /etc. But anyhow, it looks like most of the stuff in the current FHS is just tacked-on hacks. I'm not even sure you can say there is a standard really when multiple FHS-compliant filing systems can be incompatible with each other.

Now I'm vamped up about wanting to build my own workstation. I wonder if maybe I can get a broken Indigo or just the case for a good deal off amazon or ebay and replace the innards with a C120. DIY all the way!

Would be better than shedding out $2000+ to buy a legitimate one.

/sys was the historical location of the system source on 2BSD.. OpenBSD and FreeBSD maintain this by making /sys a symlink to /usr/src/sys.