New 32/64 bit Developement Boards

It looks like Linaro and ARM have been working closely with many of their partners to create a hardware spec that anyone can use to create ARM development boards. Over 10 are expected by the end of 2015, with the first one now available for $129.

Detailed specification manuals will be provided for them all, making them ideal for RISC OS Ports (I assume).

https://www.96boards.org/

“We expect to have an SoC reference document with register details published in the next few weeks.”

Nice!

Also, Mali 450 GPU. There’s a free (BSD!) driver for that (http://limadriver.org/), although it looks like the current version might only support the 400, not the 450. Hopefully it’s only minor changes required from the SW side.

It’s really time for a version of RISC OS adapted to KVM. Then Linux could be used as a first level hypervisor for all the new Cortex-A7, Cortex-12, Cortex-A15, Cortex-17, Cortex-A53, Cortex-A57 and Cortex-A72 motherboards.

One of the french users of ARM boards managed to use Pi patches for Qemu with success. So RISC OS works under ARM/Linux with Qemu. Just need to make tests for KVM now. But a port for QEMU/KVM without patches would be much better.

While a Cortex-A53 based board would be nice, the HiKey board lacks many interesting features. No Ethernet (so via USB is the only option), no S-ATA, no USB3.

So an interesting testbed for Mali and Cortex-A53, but not very interesting for the typical RISC OS user.

Almost true : there is an eMMC chip.
And it’s only the 1/96 board.

Also, Mali 450 GPU.

As most Rockchip CPU. They are so popular, but still no RISC OS for them :)

It’s really time for a version of RISC OS adapted to KVM

Shouldn’t KVM provide a virtualized environment RISCOS undestands? You don’t normally modify OS’s to run under a hypervisor, although you might want to extend them to allow passing information back to the Hypervisor, such as IP address, guest OS info etc.

One of the french users of ARM boards managed to use Pi patches for Qemu with success

I’ve tried RISCOS under QEMU, it works but isn’t that accurate due to the Pi’s SoC being undocumented, it instead provides a similar but documented SoC with some hacks to make it look like a Pi. IIRC Sound doesn’t work and there are issues with the USB stack.

My intention was to run a virtual Pi on my laptop so I could develop ADFFS whilst away from home, in the end I gave up and opted to lug a Pi around with me.

Linaro’s CEO George Grey talking all about 96Boards in a couple of videos – link

Shouldn’t KVM provide a virtualized environment RISCOS undestands?

No. It simulates an ARM computer that RISC OS does not support. That’s the problem.

You don’t normally modify OS’s to run under a hypervisor.

Yes, we don’t have to, but here it’s different.

I’ve tried RISCOS under QEMU, it works but isn’t that accurate due to the Pi’s SoC being undocumented, it instead provides a similar but documented SoC with some hacks to make it look like a Pi. IIRC Sound doesn’t work and there are issues with the USB stack.

The same here. The good point is that QEMU is the base of KVM. So patches for QEMU = patches to make RISC OS working under KVM.

But it would be much better to have a direct RISC OS support of the standard ‘KVM computer’. Then, RISC OS will be compatible with virtually all the future ARM boards with a Type-1 Hypervisor… and with QEMU too for classic emulation under Windows, Linux, OS X, etc.

Qualcomm have announced their first 96Board; the DragonBoard 410c available via Arrow for $75USD. Most importantly, the level of documentation that goes with it.

Contains a Quadcore A53 processor and supports Android 5.1, Ubuntu and there are plans to offer support for Windows 10. Nice if RISC OS was added to the list.

Any bored RISC OS developers out there, feel free to check it out at: https://www.96boards.org/products/ce/dragonboard410c

Is this worthy of a Bounty? I think so.

Lack of Ethernet might be a problem. AFAICS it has WiFi only.

Lack of Ethernet might be a problem. AFAICS it has WiFi only.

Combined with a lack of wireless support in RISC OS I’d put that down as a show stopper.

Edit: Actually, given that it is more limited than the Pi for features that RO can access I’d suggest that it isn’t worth the effort unless someone wants to spend time developing a new HAL¹ as well as a wireless support bundle.

¹ I think we should give Jeffery permission to shoot anyone suggesting that he could/should do it.

I think we should give Jeffery permission to shoot anyone suggesting that he could/should do it.

Could always say “(S)He who wants it, ports it.” ?
It looks like a reasonably nice ARM board, but given that man person hours available for RISC OS development are limited…

There are not many reasons to choose a Cortex-A53 instead of a Cortex-A15 or even a Cortex-A9 in a RISC OS context. While I don’t think that a missing Ethernet port is a show stopper (many boards use Ethernet-via-USB, so using USB Ethernet adapters like in the early BeagleBoard days is perfectly good), this specific 96Board looks not very attractive. Not very fast, not much peripheral support, not very cheap.

this specific 96Board looks not very attractive. Not very fast, not much peripheral support, not very cheap.

You mean sort of not like the Pi – for which we already have a working install :)

Is this worthy of a Bounty? I think so.

This board was announced months ago. Other are ready, but still wait for an announce… since months.
The projects seems to be dead today – or almost.

Anyway, the objective is to have around 100 boards. A port to KVM/QEMU would be better than individual ports, as we would be able to use RISC OS on all these motherboards with a level 1 hypervisor (or Linux, or future versions of Android). It’ll be a better choice for future ARM servers, as you’ll soon be able to buy ARM virtualized resources on the net. You’ll just have to send a KVM image to the server with RISC OS and VNC server, and play.

BeagleBoard X15, IGEPv5, Pyra are more important motherboards for porting RISC OS, even if more pricey. They share almost the same specs.
http://elinux.org/Beagleboard:BeagleBoard-X15

I’m in agreement with most people here that the DragonBoard doesn’t look like a good choice for the next ‘flagship’ RISC OS board. Not only is it severely lacking in features, but we also have several other ports which are yet to reach the stable release state (we don’t want to spread ourselves too thinly).

If you look at it from the perspective of the DragonBoard just being a dev board – something for us to get ARMv8 experience with – then things are more favourable. Lack of ethernet, “only” 1GB of RAM, etc., all become less of an issue. But the hardware documentation is a bit thread-bare for me to be comfortable with – the time spent getting the OS working on ARMv8 (in 32bit mode) could easily be less than the time it takes to work out how to program the video controller to get a simple display working!

To learn about ARMv8, would it not suffice to have USB working and using one of the USB graphic cards?

Yes. But it would be nice to have a direct form of video output if possible.

While this particular board doesn’t look like a good flagship, there is a spec document for a micro ATX board with Ethernet, optional SATA, etc. There’s even 64 MB of flash, so the RISC OS ROM could go in there (CMOS notwithstanding¹). There would obviously still be development required, but having a standard-sized board could mean that people are free to make RISC OS PCs in a more traditional form factor.

You could even find a “pizza box” ATX case and come up with something resembling an Archimedes :)

¹ Edit: I’m sure that there would be a way to store the CMOS settings in there; I was just thinking more along the lines of SDCMOS which presumably won’t work without modification.

It’s really time for a version of RISC OS adapted to KVM. Then Linux could be used as a first level hypervisor

This doesn’t make sense at all. By adopting other (especially not perfect) OS as a hypervisor one has to accept all possible consequences:

• no and/or complicated direct access to HDD/SSD/CD/whatever media hardware
• security features limited and/or forced by hypervising OS
• hardware support limited to whatever hypervising OS supports (yes, this means bye-bye to A7000/RiscPC/Iyonix/whatever legacy platform + probably some of current ones)
• this doesn’t really solve some problems introduced by RISC OS architecture (no SMP, no IPv6 in network stack, partially also Wi-Fi/Bluetooth support absence)
• probably broken compatibility with any/most of existing software (come on, second if not third time?)

In conclusion: dedication of insane amount of work just to break things much more than these were ever broken.

Almost true : there is an eMMC chip.

It would be nice to have support for eMMC stuff (to keep ROM and CMOS for example).

While this particular board doesn’t look like a good flagship, there is a spec document for a micro ATX board with Ethernet, optional SATA, etc.

That would be wonderful, first “real” (with PCI, real SSD/HDD/directly connected optical drives support) workstation to support RISC OS since last few years ago.

This doesn’t make sense at all. By adopting other (especially not perfect) OS as a hypervisor one has to accept all possible consequences:

It has, for one reason: any coming board will be supported by RISC OS, automatically.

hardware support limited to whatever hypervising OS supports (yes, this means bye-bye to A7000/RiscPC/Iyonix/whatever legacy platform + probably some of current ones)

No, you don’t get it. I do not say that RISC OS should be KVM only, but that we could provide a KVM port for all the boards where RISC OS is not and will not be present.
That means too that RISC OS will work on QEMU, and so on Windows, Linux, OS X, etc.

Of course the hypervisor port will be more limited than a true port of RISC OS. But it won’t limit SMP or IPv6 support, and it won’t break any software. It’s just a port for a virtual machine, managed by an hypervisor. Not different from RPCEmu use, but with more much more speed and less limits.

That would be wonderful, first “real” (with PCI, real SSD/HDD/directly connected optical drives support) workstation to support RISC OS since last few years ago.

There is already one :)

no and/or complicated direct access to HDD/SSD/CD/whatever media hardware

When direct access to hardware is provided by an hypervisor, it’s less complicated than native. Not more. Hypervisor is like a SuperHal.

In conclusion: dedication of insane amount of work just to break things much more than these were ever broken.

An insane amount of work? The idea is to dedicate the smallest amount of work for all these motherboards that are not mainstream and that will be only used by a few people. In fact, the idea is to save time. Today we support a few motherboards behind a firmware. Tomorrow we could support a few motherboards behind a firmware and all the others behind an hypervisor. More is always better than less. And yes, if a platform becomes successful, it doesn’t stop us to make a native port… later.

I don’t see where is the problem…

There is already one :)

Aren’t latest manufactured Iyonixes at least seven years old by now? Aren’t those outperformed by significantly overclocked Raspberry Pi that I wrote those words on?

Not different from RPCEmu use, but with more much more speed and less limits.

What’s the current performance penalty of running RPCEmu on ARM-based computer (let’s say under GNU/Linux)?

It’s just a port for a virtual machine, managed by an hypervisor.

Well, adding KVM only as a “backup” platform makes sense ;-)

I don’t see where is the problem…

It’s just all about not becoming another Amiga (there’s very limited choice of very expensive hardware and continuous support of even older and more expensive legacy stuff while virtual machine support is near perfect).

Aren’t latest manufactured Iyonixes

ARMx6 has native Sata, etc.

What’s the current performance penalty of running RPCEmu on ARM-based computer (let’s say under GNU/Linux)?

No JIT, so around 1/20 of real speed, with massive limits on memory, video modes, etc. And it’s emulation, not virtualization.

It’s just all about not becoming another Amiga

Different case. 1st, we have low cost hardware, old and new. 2nd, virtualization is not emulation. It’s closed to 100% speed. See it more like a super hardware abstraction layer. Amiga OS is not available under virtualization. Virtualization could be a cool way to use the 4 cores of a Pi 2.

RISC OS is the only alternative OS that still lives, natively, on low cost hardware.