Samsung S3C2451

Ultra low cost RISC OS solution for embedded market or a tablet? (or even a game device?).
http://nanopi.org/

Seems to be closed to the A9Home.

Of course, it’s no use for a desktop computer, compared to a Pi, but it’s very interesting: only embedded applications can be used under Linux, where all RISC OS applications should fit and run at correct speed.

Hmm. 790 page hardware manual for the Samsung processor. That’s better than we have for the Raspberry Pi CPU. Probably.

We’ve actually had partial S3C2440 and S3C6410 ports for a long time now, targeting the Mini2440 and Mini6410 respectively. So there’s plenty of choice for Samsung chips should anyone want to pick up and finish off any of the ports (or even try something like an A9home port).

AFAIK the ports were developed using Samsung’s manuals, so they’re certainly not the worst company when it comes to public documentation.

IMHO, we really should have specific bounties for ports…
Embedded is an interesting space for me, as AMR/KVM support for new hardware.

If we did that we’d probably end up with a thousand bounties with £5 in each :-) Just look at how many posts there are which are basically just “look at this ARM device, wouldn’t it be nice if RISC OS ran on it”

After some delay, money could be redirected to a more popular project.

Anyway, the real needed one is KVM/QEMU port, as it will mean that RISC OS will run on all motherboards with support for virtualization, so any Cortex-A7, A12, A15, A17, A53, A57 & A72 one. And of course, without virtualization, everywhere where Qemu compiles (Windows, Linux, OS X, etc.).

Apart from this and the main platforms as Raspberry Pi, there is IMHO only two needs: 1 for high performance (IGEPv5 or BeagleBoard X15); 1 or more for embedded market, with very low cost (the 7$ computer or this 16$ computer). The first one for power users, the second one because Linux can’t really go fully on this market.

Just my 2 cents.

The nanopi has a significant limitation: no video output. Ah, I thought, use a USB to HDMI adaptor… but the USB host interface is 1.1, which means it’s limited to 12 Mb/s. Screen update might be rather a problem.

The only other hope is VNC.

Once the thing is up and running, lack of video might not be an issue. It’s much more of an issue for the porting work.

Just look at how many posts there are which are basically just “look at this ARM device, wouldn’t it be nice if RISC OS ran on it”

Well, you could discount the majority by saying “show me the datasheet¹”. Without a lot of low level information, porting an OS will be practically impossible. It depends upon much more “knowledge” than a list of where the GPIO is and the sort of rubbish you might find in a typical datasheet (if you have even that much).
One of the big stumbling blocks is that some chip bakers are so paranoid about the IP in their video hardware that they would prefer not to describe the video section at all – even as “a dumb framebuffer”, which is an additional complication that would affect the ability to port something.

¹ It is not without some irony that I note that the Pi would fail this test… Details of the GPU is basically "The VideoCore section of the RAM is mapped in only if the system is configured to support a memory mapped display (this is the common case). with no GPU specific information whatsoever.

the second one because Linux can’t really go fully on this market.

Linux is quite active in embedded that needs some grunt work behind it – from my (in)famous PVR to practically every broadband router on the planet (though a fair few of those use MIPS, not ARM). I would imagine smart printers and the like are also Linux based.
It can be quite instructive to find the debug serial port and watch the output as the thing boots (examples can often be found online).

RISC OS might score better for size, you could get away with maybe 8MiB RAM and 4MiB Flash for a basic installation, something that would be unheard of with modern Linux; however RISC OS fails in many ways – we don’t have the concept of “background process” and since userland modules run at the same level as the kernel, one stack error there could risk freezing the entire machine.
That isn’t to say that RISC OS would be useless for embedded; I just think a hardware manufacturer would prefer to grab a Linux available for their chip and throw on some sort of appropriate UI and get the machines out the door… I don’t think so many hardware makers really understand (or care about) the software side, if it is “tried and tested” they’ll use it and ignore the complexities (like, uh, how many printers have had the default root on a telnet server? – http://hackonadime.blogspot.fr/2011/12/hacking-printers-pjl-basics.html?m=1).

no video output

There is an LCD output. So a portable device is possible (a calculator would be great).

Anyway, the most important part is that there is a GPU, so a full version of RISC OS, even without a connected screen, can work on it (so we can use task windows to multitask things).

Linux is quite active in embedded that needs some grunt work behind it

Yes, but not the full desktop stack.

I just think a hardware manufacturer would prefer to grab a Linux available for their chip and throw on some sort of appropriate UI.

Of course. I was thinking of us, who could wan’t to market products around ARM+RISCOS+ASM/BASIC/Whatever.