ARM-powered computer firm in RISC OS port talks

US-based company Genesi, which builds ARM Cortex-powered appliances that could be compatible with the RISC OS Open Beagleboard work, is said to be in talks with RISC OS companies over a possible port of the OS to its products. It's hoped ROS 5 could be made to run on the lightweight EFIKA MX Open Client, which sports a 800MHz Cortex-A8 processor, 3D graphics hardware, 512M RAM, wifi networking and more. Genesi analyst Matt Sealey said: "RISC OS is really popular in the UK and the last dedicated RISC OS box - the Iyonix - has been discontinued for six months. We are currently questioning the relevant companies in the UK, including [ROS 5 owners] Castle, about collaboration and marketing efforts, and the support they'd need to make it a reality." The EFIKA MX Open Client costs about 160 quid in real money.

Click here to visit this news quickie

Previous: RISC OS Open seeks rep for Acorn World event
Next: Beside Drobe, where else do you get your RISC OS news?

Discussion

Wow. Not one, but two new computers with RISC OS either being ported, or probably going to be ported, to them. Very good news. I have been hoping for some time that the most serious of the A9Hom'e limitations (disc corruption; failure of the USB stack to ignore HIDs it can't use) would be fixed. There seems little likelihood of this happening now - otherwise it would have - so I think my money is going on the new targets instead. davehigton on 30/8/09 8:07PM [ Reply | Permalink | Report ]

Hi Dave, Yes, the proposed machine sounds like it would be faster than Iyonix which is the point at which I'll buy. Sorry to hear that the A9's still got issues. It was of no appeal to me as it wasn't a step on from what I already had. I know you're very interested in USB so I can see that problems with the stack would irritate and frustrate. I guess the problem is that the pace of development in the rest of the computing market is relentless and the A9 is already starting to seem like an older machine... martin on 31/8/09 9:07AM [ Reply | Permalink | Report ]

It's a shame the last RISC OS computer to be bought to market hasn't been discontinued, and the Iyonix wasn't a dedicated RISC OS box, but other than that, he seems to know his stuff! rjek on 30/8/09 8:51PM [ Reply | Permalink | Report ]

Hi Rob, Ah yes, a Rob criptic comment but you are right if you mean what I think you mean. The A9 came along later than the Iyonix and I guess your other comment is referring to the fact that it was developed from a set top box. Are Castle still in the set top box market ? I ask because I passed a stack of them in Tesco going for £15 each - not much money to be made there, surely, unless you can shift thousands of them fast. Regards, Martin martin on 31/8/09 9:11AM [ Reply | Permalink | Report ]

This IS good news indeed...(hopefully) Genesi do have a proven track record for supporting minority platforms - MorphOS (an AmigaOS clone) for instance... ...from what I know them their point of view tends to be: If we've got the hardware & you can make it work then we'll support you. I wonder, could this be a new opening for RiscOS to break into the developing 'lightweight' platform market? Ok, it's unlikely... Charlie on 30/8/09 10:50PM [ Reply | Permalink | Report ]

While this is good news for the platform, I'd be a little bit cautious of Genesi, a few years ago there was a dispute over pay between Genesi and the MorphOS developers as well as the copyright: [link] solsburian on 2/9/09 8:59AM [ Reply | Permalink | Report ]

Really a good news. Let's hope fights between companies about the RISC OS ownership will not come back ... Xavier on 31/8/09 8:14AM [ Reply | Permalink | Report ]

Me too. But there are several ways it can be avoided. 1. sell the machine as is and have RISC OS 5 as a supported OS, with an easy installer. 2. It looks like a thin client hardware to me, I wonder how close to the RISC OS definition it is. 3. Perhaps ROL could provide (for a per unit fee) some of its commponents and along with that an agreement that all units sold with it are not in dispute. jess on 2/9/09 10:04AM [ Reply | Permalink | Report ]

Good news, though I think it is a bit of an overstatement that "RISC OS is really popular in the UK". torbenm on 31/8/09 9:23AM [ Reply | Permalink | Report ]

Ssshh! freder on 31/8/09 11:18AM [ Reply | Permalink | Report ]

For Castle, the Marvell Kirkwood platform would make a lot more sense. There is ready-made hardware available like the OpenRD platform (rd-client and rd-base), which has the added advantage of being based on ARMv5 instead of being a Cortex platform with its issue regarding non-aligned memory access. And after all, 1.2 GHz is a lot better than 0.8 GHz hubersn on 31/8/09 11:50AM [ Reply | Permalink | Report ]

But, a 1.2 GHz Sheeva might not be as fast as an 800 MHz Cortex-A8, especially if it's one of the out-of-order designs. It all depends on the CPU's design. After all, a 600 MHz Cortex-A8 destroys a 600 MHz XScale in performance... bhtooefr on 1/9/09 1:22AM [ Reply | Permalink | Report ] The Sheeva core is pretty fast, all told. It's difficult to measure their comparitive performance, because they have differing features (iWMMX2 vs NEON, etc). Also, A8's VFP is astonishingly slow, compared even to ARM11. rjek on 1/9/09 9:10AM [ Reply | Permalink | Report ] Well. I think you're comparing an XSCALE and a CORTEX. ARM Ltd say that the Cortex is 30% faster than the previous generation, same clock speed. Xavier on 1/9/09 9:53AM [ Reply | Permalink | Report ] The point of my post wasn't the XScale/Cortex-A8 comparison, it was the fact that we don't know how Sheeva and Cortex-A8 compare, and therefore, the MHz myth definitely applies to that comparison. XScale/Cortex-A8 was only used as an example of the MHz myth applying to ARM. bhtooefr on 1/9/09 1:25PM [ Reply | Permalink | Report ] Actually, I own both a Cortex and a Sheeva machine, so maybe it is time to run a few benchmarks. One is a 600 MHz Beagleboard, the other a 1.2 GHz Plug. hubersn on 1/9/09 4:15PM [ Reply | Permalink | Report ] Warning: The Sheevaplug does not contain a CPU with a Sheeva core. It's a Kirkwood. rjek on 1/9/09 4:55PM [ Reply | Permalink | Report ] According to official Marvell documentation, both the Kirkwood and the Discovery Innovation series of CPUs contain the Sheeva core. hubersn on 1/9/09 10:00PM [ Reply | Permalink | Report ] Linux uses significantly different code on Kirkwood to other Sheevas; the word is simply a marketing term, and depending on the phase of moon means different things, which is why I said be careful rjek on 1/9/09 11:13PM [ Reply | Permalink | Report ] I don't know the deep technical details of the silicon involved, but it looks plausible that the PXA168, the Kirkwood series and the Discovery Innovation series use the same or a very similar CPU core - if Marvell calls this core "Sheeva", it would be sensible that we use the same wording and not some arbitrary decision from Linux kernel hackers. And that vastly different SoCs need significantly different (initialisation) code is not really surprising. hubersn on 2/9/09 12:38AM [ Reply | Permalink | Report ] No, really; instruction timings, memory access speeds, contents of system control co-processor registers, core features, etc, all differ wildly. Sheeva's a marketing term, and their efforts to merge the multiple different core designs (such as XScale and Ferocean) under one roof. rjek on 2/9/09 1:09AM [ Reply | Permalink | Report ] However, hubersn was suggesting a Kirkwood port, so might as well bench it. I do recall both out-of-order and in-order cores under the "Sheeva" name. That's a huge difference - like calling an A5000 another kind of RiscPC. Of course, both the XScale-derived cores and the Feroceon-derived cores are ARMv5TE... take that however you will, but I know at least WinMo 7 is rumored to require (for Chassis 1, anyway) ARMv6. bhtooefr on 2/9/09 5:55AM [ Reply | Permalink | Report ]

How does this benefit desktop users? AW on 31/8/09 12:21PM [ Reply | Permalink | Report ]

By being an ARM-powered desktop computer that's faster and more capable than the Iyonix and A9home at a fraction of the price? If it gets a RISC OS port. diomus on 31/8/09 12:54PM [ Reply | Permalink | Report ]

How is it more capable? 512MB RAM, 4GB hard drive. DVD drive? 2D graphics acceleration like Geminus? AW on 31/8/09 8:14PM [ Reply | Permalink | Report ]

Faster CPU, much faster RAM with L2 cache, VFP, digital video output, integrated video decoder. Looks like a good deal to me. hubersn on 31/8/09 8:53PM [ Reply | Permalink | Report ] But much smaller memory, extremely small hard drive space and no DVD AIUI. AW on 1/9/09 9:28AM [ Reply | Permalink | Report ] Perhaps you'd like to fund your own perfect machine. rjek on 1/9/09 10:13AM [ Reply | Permalink | Report ] No Andrew, wants YOU to fund his perfect machine. He also wants you to fund his perfect software and make him tea. IvanDobski on 1/9/09 12:29PM [ Reply | Permalink | Report ] I do have to admit it; I make a damned fine cup of tea. rjek on 1/9/09 4:57PM [ Reply | Permalink | Report ] Pot or bag? Monty on 3/9/09 10:52AM [ Reply | Permalink | Report ] Loose tea in a pot, of course. rjek on 3/9/09 8:46PM [ Reply | Permalink | Report ] Well, Andrew's going to want a bag then. IvanDobski on 4/9/09 2:43PM [ Reply | Permalink | Report ] The system has USB2 though, so you can easily add a DVD drive and external hard disc. Adding memory is less feasible, but to be honest, 512MB sounds like plenty to me. ninja on 1/9/09 12:03PM [ Reply | Permalink | Report ] The SSD is attached by PATA, according to some stuff that Genesi posted on their forums. So, replace it with a hard drive. Although in that box, it's probably a 1.8" SSD we're talking about, or worse, a CompactFlash card, but there's hard drives available for both form factors. (But, in the CF form factor, flash makes more sense.) bhtooefr on 1/9/09 1:29PM [ Reply | Permalink | Report ] Hopefully Castle will improve the situation somewhat. AW on 1/9/09 1:39PM [ Reply | Permalink | Report ] Actually the SSD is attached by PATA soldered to the board in the current design revision. There's no reason you can't use an external USB drive to boot from (or an SD card) and the same for CDROM. mwsealey on 2/9/09 1:43PM [ Reply | Permalink | Report ] Oh. But, that does mean that a future revision (or a revision for Castle, for example) could add a connector for a real drive. bhtooefr on 2/9/09 2:02PM [ Reply | Permalink | Report ] In theory, yes, although if you wanted CompactFlash (as in NAND with a PATA interface) it would be easier to use the internal SDHC card slot and grab a nice, fluffy 32GB Sandisk card. A 1.8" ZIF connector for microdrives would an expensive solution when you consider the price of these drives (130 quid for 60GB - that's almost as expensive as the system itself), but possibly worth it. All in all it may be far more likely that we integrate some kind of eSATA connection on the board, and have a little stackable drive case you can plonk underneath it connected by a short cable. mwsealey on 2/9/09 2:09PM [ Reply | Permalink | Report ] How much slower is an external USB drive to the Iyonix hard drive? AW on 3/9/09 11:04PM [ Reply | Permalink | Report ] You'll get 20-30MB/sec out of a good one. Assuming a good high-performance USB stack and good IO layer. Of which, the Iyonix has neither rjek on 3/9/09 11:27PM [ Reply | Permalink | Report ] "Much smaller memory" doesn't make a great deal of sense. I have one Iyonix with 1GB RAM and one with 512MB RAM, the one with the smaller amount of RAM isn't really very limiting at all under RISC OS. The only time the extra RAM really comes in useful is with Photodesk, which for a long time couldn't use it anyway. Improvements in performance are far more important than worrying about "only" having 512MB RAM in RISC OS. dgs on 2/9/09 8:58PM [ Reply | Permalink | Report ] What Geminus amounts to is an old Amiga feature called Smart Refresh - where if you overdraw something with a window, the OS takes a snapshot of the window underneath and when you drag away, it restores it. It takes all the traditional "send a signal to the app to repaint" methodologies away. Geminus is just clever bitmap caching and redraw.. however with a UMA graphics system (i.e. embedded in the chip, uses the DDR2 RAM) there's very little benefit in caching bitmaps in "graphics" memory. FYI the graphics core in the iMX515 is practically identical in feature set to the one in the XBox 360 - just running at a lower clock rate. [link] mwsealey on 2/9/09 2:03PM [ Reply | Permalink | Report ]

This is great news! If everything happens this means we will get a supported Cortex computer + Jeffrey will get help porting RO5 to the Cortex line! highlandcattle on 31/8/09 8:52PM [ Reply | Permalink | Report ]

Sounds good to me. I'm still waiting for my touchbook to arrive. That will open up a whole more options. 1234 on 1/9/09 1:22PM [ Reply | Permalink | Report ]

I notice a laptop/netbook on their site with similar specs. I hope they are compatible. I also notice they come with ubuntu, (shame it's not mint) so as long as they can dual boot, things unavailable for RISC OS are much less important. jess on 2/9/09 10:36AM [ Reply | Permalink | Report ] Yes they are broadly compatible, and our firmware/BIOS abstracts most of the differences. You will be able to run exactly the same Linux kernel or RISCOS ROM on top of them (and ideally, any other implementation of our firmware - we have an EXCELLENT relationship with Marvell for example, as we used their chips a lot for the Pegasos As for Linux - believe me, once we have Karmic support finished we will be running after all the other Linux distributions (backport to Debian Sid, grab all the Ubuntu derivatives - Mint is first on the list - Fedora and OpenSUSE when they get their armel ports out of the door). Actually supporting Mint without any armel support from the main distribution is a little more tricky than taking a Linux distro that already HAS a port and pluggin in a few custom packages, but the Debian->Ubuntu->Mint legacy really works in its favour here. mwsealey on 2/9/09 2:17PM [ Reply | Permalink | Report ] Interesting - so a port to your hardware would be a port to your firmware (which I guess is Aura), and so a port to any other Genesi device would just (ha!) need to consider ARM instruction set differences, pipeline lengths, that sort of thing? I quite like that idea, though it doesn't lessen the need for a good HAL in RISC OS if it's going to be truly portable. ninja on 2/9/09 6:28PM [ Reply | Permalink | Report ] Aura is our brand for the abstraction layer and whatever firmware technology sits on top - it will run standalone but it's easier if you have OF or UEFI on top - this abstracts the hardware description so you don't need to know really which chip you're running on exactly (given that you can have gone through 4 or 5 chip revisions on something like the Beagleboard) or which revision of the board you're running on hardcoded or making a rough estimate in your code. U-Boot has the DTB for this but OpenFirmware preceded that specification by a good 15 years. We have a lot of experience here. Indeed, the HAL would have to target Aura. Optimization is always an issue but you can boot any code build for previous ARM architectures - within reason - on newer ones. A kernel built for ARM5TE will run fine on ARM7A.. the idea is you can grab something you already got working et voila.. instant system. As it stands the similarity between the device tree Aura produces (based on OF) and the one bundled with the Beagleboard are similar enough that it should be able to support them both in the same ROM. You would have to write some drivers, deal with quirks in the hardware that weren't abstracted (black/whitelisted USB devices etc.) but they are significantly reduced. mwsealey on 2/9/09 8:25PM [ Reply | Permalink | Report ] A laptop with dual boot mint and RISC OS would be ideal for me. (Have you concidered a USB socket facing up on the top of the screen for GPRS/3G dongles?) Is the hardware powerful enough to decode and display HD video? If so a desktop machine with GeexBox and RISC OS would be nice. Will an ATX board be available for building your own machines? And would you be able to include ADFS support in the linuxes for the machines? jess on 2/9/09 8:10PM [ Reply | Permalink | Report ] The Netbook will have support for 3G and Wireless internally (you just need the right card). The hardware can decode certain profiles of MPEG4 and H.264 video (all the useful ones) at 720p. Geexbox on the Open Client is something someone will have to port.. HDMI output should come in handy here (no HDCP though, 720p playback is DRM restrictions notwithstanding - if we ship hardware capable of playing them back we are legally obliged to support the DRM too) ADFS as in Active Directory logins? Yes. mwsealey on 2/9/09 10:04PM [ Reply | Permalink | Report ] And ATX? No. The high integration of ARM SoCs means ATX somewhat belies the need for huge motherboards. We're pretty much done with motherboards the size of a volume of the Encyclopaedia Britannica.. the modern alternative being DVD, we settled on something DVD-case sized. The next step; about the size of a cigarette packet, and then we go on to neural links mounted into Bluetooth headsets, right? I can't wait for the RISC OS Brain Interface mwsealey on 2/9/09 10:11PM [ Reply | Permalink | Report ] "And ATX? No. The high integration of ARM SoCs means ATX somewhat belies the need for huge motherboards." Micro-ATX and ITX boards still have a use; it means there's a bunch of off-the-shelf cases you can use. rjek on 2/9/09 11:54PM [ Reply | Permalink | Report ] But presumably if the form factor allows, the boards would be better housed in a 3.5" or 5.25" drive bay, rather than making them artificially larger? md0u80c9 on 2/9/09 11:58PM [ Reply | Permalink | Report ] Depends. RJ45, USB, sound, and perhaps legacy ports, take up a lot of width. There's another issue I just remembered, though: most ATX power supplies won't turn on ARM-based designs because they don't believe they're turned on they consume so little; the PSU can't stabilise. We get that a lot with the ATX S3C2410 board from Simtec. rjek on 3/9/09 10:53AM [ Reply | Permalink | Report ] I didn't mean full ATX sized boards, just ones that were compatible with ATX cases. Since there are no pci cards, it would just need to fit on the four mounting points nearest the cutout and have the relevant connectors on the right side. (OK the power supply might need changes too.) jess on 3/9/09 7:41AM [ Reply | Permalink | Report ] ADFS is a class of file systems used by RISC OS for floppy and hard discs - open drivers have been available for this for years now, so I can't believe it would be hard to apply this so the linux side could see the RISC OS side's discs. It used to require a rebuild of the kernel last time I used it, but that was many years ago. ninja on 3/9/09 12:53AM [ Reply | Permalink | Report ] Oh okay. We can build that in to our shipped kernel if you like.. that's almost too easy What I would like is a pointer to some on-disk layout documentation for the format so we can look into implementing it in firmware (then you could boot the ROM directly from the ADFS filesystem) mwsealey on 3/9/09 3:03AM [ Reply | Permalink | Report ] Does your firmware allow the posibility of the OS using filesystems it implements? ie could RISC OS get access to new filesystems and possibly improved performance by using the firmware? jess on 3/9/09 7:52AM [ Reply | Permalink | Report ] Why would a filesystem loaded from firmware give beter performance? Maybe the firmware can emulate one or more poduleroms (from file?) supporting non-RISC OS filesystems and/or partitontables so you can boot from those? A bit like you can put drivers in Amiga Rigid Disk Block. But for that the foreign filesystem needs to have implemented RISC OS filetypes in some way. egel on 3/9/09 10:12AM [ Reply | Permalink | Report ] Because filesystem performance is a weak point for RISC OS. If the one in firmware is better (eg a port from linux or BSD, as opposed to a simple bootloader) and could be talked to (like Hostfs on an emulator) then that might help with one of the worst RISC OS performance problems. jess on 3/9/09 11:06AM [ Reply | Permalink | Report ] There's nothing inherently bad about FileCore's performance. The problem is RISC OS's shocking IO layer and wastefulness of memory. And some firmware isn't going to help that. rjek on 3/9/09 11:29PM [ Reply | Permalink | Report ] I can't find any documentation for ADFS-E and F formats as used by RISC OS - all my googling seems to bring up are details of the 8-bit ADFS implementation from the BBC micro. Apparently the modern linux kernel has an ADFS kernel module which can read E and F format discs (certainly floppy discs - I believe hard discs are formatted the same). This may be as good a starting point as any. Abstracting away the disc interface would certainly be a good idea, since RISC OS's ADFS implementation doesn't understand partitions, so can only use the first partition on a disc. If the interface presented a certain parition as being a full disc to RISC OS, the RISC OS partition could be put anywhere. ninja on 3/9/09 1:36PM [ Reply | Permalink | Report ] There's plenty of information on ADFS, both '-' and '+'. I implemented DiscKnight purely from publicly available information in the PRMs and RO4 (nee Ursula) documentation. druck on 3/9/09 7:15PM [ Reply | Permalink | Report ] Reading from GPL code is bad for our firmware. We can't be tainted by stuff like that in certain parts of R&D Documentation would be best, we can get by with a simple on-disk format, like you can get for XFS or ZFS or other filesystems. Can the current RISCOS read FAT fairly reliably? I would assume so, in which case, there is probably not going to be much trouble having a boot partition of FAT format containing ROM files and other boot-time support, and then the rest of the OS inside another partition.. mwsealey on 7/9/09 5:59PM [ Reply | Permalink | Report ] It can read DOS drives up to 2GB. But would it actually *need* to? ie would the RISC OS "ROM" actually have to be visible to anything other than the loader? (Of course upgrade might be tricky if it couldn't) Is the idea of RISC OS using the firmware's filesystems silly? jess on 7/9/09 8:25PM [ Reply | Permalink | Report ] 1080p isn't on the cards then? A nice low energy replacement (that also runs RISC OS) for the x86 monster in the home cinema system would be nice. (And I don't have DRM replay anyway.) jess on 3/9/09 7:27AM [ Reply | Permalink | Report ] Many of these SoCs are meant for netbook or even cell phone applications, so you're lucky to get 720p out of them. Now, if these things move more into the set top box space, you could see a PVR* using a Cortex-A8 SoC that can output 1080p. (And, such an SoC would also need SATA, which would be nice to have.) With an SoC like that, one could create an even more desktop-oriented ARM-based platform. * Before someone starts a 238 post offtopic tangent flamewar that doesn't answer an original poster's question, I'm referring to a device that has some source of TV signal going into it, records that TV signal to a hard drive for later playback, can pause live TV (by caching it to the drive,) and then outputs to a TV. bhtooefr on 6/9/09 5:46AM [ Reply | Permalink | Report ] 1080p is on Freescale's roadmap. mwsealey on 7/9/09 5:55PM [ Reply | Permalink | Report ] Which presumably means it will be on yours, and if RISC OS were supported on the current models, it should also work on it? Does the 720p support mean it can display 1080 material, but only at 720 or is it limited to 720 material and lower? jess on 7/9/09 8:31PM [ Reply | Permalink | Report ] It depends; if it is the framebuffer/GPU that limits the resolution to 720 lines, then perhaps. If it is the acceleration functions and general grunt of the CPU that limits it to 720 lines, then no. Decoding 1080p at 25fps requires not only unspeakably enormous amounts of data processing, it also requires unspeakably enormous amounts of memory bandwidth. rjek on 7/9/09 9:03PM [ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

+++ Message board +++

Read messages or start a new thread

Search the archives

Today's featured article

Wakefield 2004 show report
Views from the Launchpad
 34 comments, latest by mavhc on 26/05/04 6:02PM. Published: 22 May 2004

Random article

MSN to lock out unauthorised clients from October
MS asking for licenses, so alternatives?
 24 comments, latest by mavhc on 6/9/03 6:03PM. Published: 31 Aug 2003

Login

Useful links