Utilite – a nice Cortex-A9 box

The Compulab Utilite looks like a very nice little desktop machine. Some very serious specs there.

That would suit me very nicely. Nice box size of a router, ports pointing the right way, mSata SSD so silent, clock and flash ram for configuration ticks all of the boxes for me.

Cortex-A9 is sooooooo yesterday. There is hope for an updated PandaBoard featuring OMAP5 with Cortex-A15 and 1.7 GHz, S-ATA, Gigabit LAN and a bunch of very fast RAM.

Cheap compared with the Cortex-A15 though.

Yes faster would be nice but I don’t want a bareboard computer. A small box with fast internal SSD, Gigabit LAN and up to 4gb ddr3 ram is good enough for me. It would be a nice replacement for my Iyonix.

I received my OUYA a few days ago. Would be a nice little box for running RISC OS.

I’m inclined to believe that a 1.2GHz quad-core Cortex-A9 is fast enough for anything I could ever want to do with RISC OS, and such a complete and well-specified package is an attractive prospect.

I’m inclined to believe that a 1.2GHz quad-core Cortex-A9 is fast enough for anything I could ever want to do with RISC OS,

Word.

I notice a lack of power when trying to get a (~700MHz) Pi to play an AVI, as compared to a (~1GHz) OMAP. But since both are stuck using software video decoding splatting data directly into the video memory, both are kind of Made Of Fail when it comes to comparing MPlayer on RISC OS to MPlayer on a PC. This isn’t the fault of MPlayer, it is the lack of GPU support.
That is where I notice it.
Otherwise, the only other difference is that the Pi starts up a hell of a lot quicker than the Beagle xM.
For everything else, NetSurf loads near instantly. OvationPro loads near-instantly. I have an Obey file to load the development tools and !Zap, and that starts up near instantly. I press Ctrl-Shift-C in Zap and my code builds near instantly.
I’m sure if I did hard’n’heavy work I would appreciate the entra 300MHz the OMAP offers over the Pi; and I would then appreciate the 1.2GHz quad-core jobby, and then get ecstatic about the Cortex-A15 at silly clock speeds.

But for me, right now, both boards running RISC OS are “bloody fast”¹ and that’s quite fast enough. When I can ask the computer to do something (load the browser, build the project, …) and it is ready before I am, then that’s quite fast enough.

I would give moral support to any project to bring RISC OS to a wider range of hardware; however let us not forget that there still are some biggies that need to be looked at across the board – namely what to do with other cores and how to talk to GPUs, more consistency in the USB stack(s)², and of course <insert your favourite wishlist item here>. ;-)

¹ That’s the technical term for “whoa, duuuuuude!”.

² Kudos to Colin for his work here, BTW.

I’m inclined to believe that a 1.2GHz quad-core Cortex-A9 is fast enough for anything I could ever want to do with RISC OS, and such a complete and well-specified package is an attractive prospect.

Short of an under-employed code-fairy deciding that multicore support was useful and devoting some f the “free” time I think the clock rate and speed of peripherals like network and “disk” storage is probably more important.

Are you looking at the same thing as me? Other than the processor what else is slow? I obviously don’t understand something. Are mSata SSD discs slow? GigaBit LAN slow? I admit I don’t keep up with things these days so would be interested to know.

Other than the processor what else is slow? I obviously don’t understand something.

My comment was pointing out that dual core, quad core, or 64 core makes no difference to RISC OS in the available RO version as it only runs in a single core¹. So, CPU clock rate becomes far more important and a 2GHz A15 with just one core in use is more useful than a quad A9 at a slower speed.

Ah right I see what you mean. But think of the sleepless nights trying to work out what to do with 3 cores standing idle “I’ve paid for them so I’m gonna use them”. We could have competitions – winner gets a core named after them (like a hospital wing).

But think of the sleepless nights trying to work out what to do with 3 cores standing idle “I’ve paid for them so I’m gonna use them”.

I like twiddling, I had actually contemplated getting a chromebook to see what I could twiddle with.

We could have competitions – winner gets a core named after them (like a hospital wing).

Well naming a hospital wing after a person would be preferable the stuff at <cough, gagging clause¹> – The building curves, but the bit that points North is labelled “West Wing” (so the later opening bit that points South-West got labelled “East Wing”), the shops near the entrance are “The Mall”, the A&E is labelled ED (apparently ER was a step too far) and the guest waiting area was )temporarily) “The Green Room”²

¹ Those who know me will know where it is – I have no doubt other establishments have similarly twee labelling.
² The culprit has left

The Utilitite has now been spec’ed and priced: $99 for the 1GHz single core with 512MB, 4GB SD and one HDMI and ethernet. $159 for dual-core, 2GB, 8GB SD, dual-head HDMI&DVI, two ethernets, wifi and bluetooth. $219 for 1.2GHz quad-core, with 32GB mSATA SSD.

More here.

Specs of the three models now here.

Specs of the three models

Where did that Freescale port get to?

I have a sabrelight board with the i.mx6 here, feel free to contact me…

An i.MX6 port is definitively a good idea :
- Genesi USA will use i.MX6… The DIY Laptop from Andrew ‘bunnie’ Huang too.
- It’s the same for the Wandboard… and of course the Utilite.

The i.MX6 can drive two screens, and the graphic specs seems to be quite opened. It can also drive one Sata disc. IMHO, it’s a very good choice for future RISC OS computers. Even with more than one core. Of course, RISC OS in not multicore ready, but it’s not such a big deal…

If you just want to make calculation on the other cores, for example the decoding part of mplayer or an x86 emulation, the OS just needs to fire up the other cores with their own memory space, then to send code to them and get the result. That’s the way Amiga OS manage multicore systems (in fact, it goes even further by making light copies of the OS running on each secondary core).

The Sata port was the main point for going for the i.mx6, and it might also be interesting that there is a project called ‘lima’ that might help in order to use the graphics processor(s) in the future.
Simtech once had multiprocessor extensions that allowed to use the extra ARMs to do additional jobs, but due to low marked spread it was not used much (AFAIK). But when most users have additional cores doodling around doing nothing, this would probably change the situation.
Does anybody know about the ups and downs of the simtec Multiprocessor solution? (Could it at least be used as a starting point?) The ‘light copies’ approach is also an alternative I thought about. Riscos is light anyway ;-)

simtec Multiprocessor solution

The Hydra? Has anyone reported doing anything along these lines since this 2003 Drobe piece?

The Hydra? Has anyone reported doing anything along these lines

But why would anyone?

Yep, Simtec did use the strategy I suggest (and that the Amiga community uses today) : a light bootstrap/os on other cores, just to run specific tasks (mainly calculation, with no direct access to 100% of the main OS). Much better than nothing since the kernel of RISC OS, the Wimp, etc. really don’t need to use several cores. That’s also very interesting in term of power management, since you can switch off the secondary cores very easily. They are just seen as “additional power”. And the tasks that run on it as sort of “light threads”… threads that can access only a small part of the main API. A very common approach.

Unfortunately that approach is a complete pain for programmers, and is (potentially) why Hydra never took off.

The rest of the world uses a SMP threading model for their PCs, so unless there’s a secret cult of programmers somewhere that worship asymmetric threading and are just waiting for RISC OS to gain support for it I don’t think we’d get very far by using it.

In terms of power management, well, in an SMP approach there’s nothing stopping the OS from turning off some of the cores if it wants (hardware power management permitting!). It just needs the OS to have the right logic in place to know when it’s better to turn on extra cores and schedule threads on them or leave them off.

The Hydra may have found some interesting uses but as it only supported ARM610 & 710 CPUs and StrongARM had just come out with 3-4 times the power of a 710 it was no contest.
Peter Bonder’s suggestion around the time of Black Thursday was that Phoebe have its single CPU board replaced with a dual one and expected that someone could find a way to use the extra CPU.

Jeffrey, you’re perfectly right on one point: SMP is a more powerful approach. But it’s more complex to implement. Let’s face it: a version of RISC OS that will manage ACPI, SMP, Preemptive multitasking and memory protection, is a dream. With the current community it’s simply impossible to make it. To get light threads working is a short term goal that would permit to exploit the power of extra cores tomorrow… and perhaps to gain new developers.

Think about it: if we can implement light threads in six months and complete SMP in five years, would it be really a problem to get light threads first and to wait six months more for SMP?

The browser market choose the light threads approach as a short (middle?) term solution, with a great success. That’s the way the JavaScript workers are implemented. And it works. The idea is to have light threads, that are limited to a small subset of the system (IPC and memory). So we can use SMP without the need to have a complete rewrite of the OS. On the other hand, once implemented, it’s perfectly possible to implement a SMP compliant version of core subsystems.

We could imagine, for example a drawmodule with a light thread for calculation and a classic part to communicate with the wimp. Once light threads available, it’s really easy to use them (it’s threading, with limits that are not really important in a thread context). The same with all the parts of the OS that needs to make big calculations, without too much accesses to disk, graphic stack or network stack. And perhaps later with (almost) all parts of the system.

Light threads could be a path to SMP, as it was for some BSD systems. That’s not a goal, that’s a step in a strategy of evolution. There are others. A complete rewrite of the OS, with total incompatibility with current software, is not a strategy of evolution. It’s simply another OS :) Dreams and reality.