Yet another potential RISC OS target?

If Adrian isn’t going to the London show and we (University of Cambridge Computer Laboratory) get one of our alpha boards (not sure of the timelines on this), I might be able to demo something (presumably on the ROOL stand?). Adrian, mail me nearer the time if you want to follow this up.

I made the case for RISC OS to another of the trustees this afternoon ;)

Presumably the GPL USB driver isn’t a showstopper: it can be argued that the ROM image is just a filesystem, so a GPL component in the ROM would be OK if source is published (or even a mixed GPL/BSD component). Stallman has been asked about this specific issue (what ‘linking’ means in a firmware context) and said he isn’t interested, so I don’t think there’s any final verdict on this question.

ROOL would be very interested in hosting any ports (or ports in progress) on our stand at the London Show. Please drop us a line at info@riscosopen.org and we’ll see what can be sorted out.

While everybody in RISC OS land would love to see newer, faster hardware the Raspberry Pi might offer a few decisive advantages. It’s been very interesting to follow the discussions on the Register re the “Behind the Screen” initiative. There seem to be those who grew up with “learning how to use MS Office productivity software” and those learning how to program Acorn kit. The same is true on the Raspberry forum. There’s a lot of fondness for it and even if memories don’t necessarily translate into crowds of new users the actual development of RISC OS could certainly build on it.
Ubuntu dropped support for the ARMv6 so that won’t be an option. Who knows if the availability of RISC OS on the Raspberry Pi wouldn’t renew some interest? I’m only guessing but the percentage of BB developers with a past and willingness to have a look at RISC OS must be marginal in comparison. So even if the hardware would seem like a step back, supporting the Raspberry might turn out being a huge benefit for the platform. /br

This however sounds a bit worrying:

Patric, did you miss Adrian Lees post here earlier ?
It sounds like we have an inside man !!

GPU

Apparently, "the binary blob on the GPU is irrelevant to 99.9999% of the prospective user base. You cannot program it without very expensive compilers and assemblers. You need years of experience in it to make it do anything because it is very VERY complicated. Thousands of registers, custom SIMD instruction sets etc."

@Tank let’s hope for the best then!

This is what Eben himself said:

The GPU interface is via a closed-source userland module, which communicates via a proprietary (but GPL’d) stream interface in the kernel to a RISC core on the GPU side. No AES coprocessor I’m afraid; wouldn’t want RP to be a munition, would we?

New article with video footage and some nice shots
on geek.com

Alex Bradbury (who’s working on the Raspberry Pi Linux distro at the moment) pointed out that the Synopsys dwc_otg driver has an almost-BSD licence:

 * Synopsys HS OTG Linux Software Driver and documentation (hereinafter,
 * "Software") is an Unsupported proprietary work of Synopsys, Inc. unless
 * otherwise expressly agreed to in writing between Synopsys and you.
 *
 * The Software IS NOT an item of Licensed Software or Licensed Product under
 * any End User Software License Agreement or Agreement for Licensed Product
 * with Synopsys or any supplement thereto. You are permitted to use and
 * redistribute this Software in source and binary forms, with or without
 * modification, provided that redistributions of source code must retain this
 * notice. You may not view, use, disclose, copy or distribute this file or
 * any information contained herein except pursuant to this license grant from
 * Synopsys. If you do not agree with this notice, including the disclaimer
 * below, then you are not authorized to use the Software.
 *
 * THIS SOFTWARE IS BEING DISTRIBUTED BY SYNOPSYS SOLELY ON AN "AS IS" BASIS
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE HEREBY DISCLAIMED. IN NO EVENT SHALL SYNOPSYS BE LIABLE FOR ANY DIRECT,
 * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
 * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
 * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
 * DAMAGE.

So it might not be licence-incompatible. Whether it’s a useful target I don’t know (I’m not familiar with the BSD USB controller environment). There’s a FreeBSD project for porting USB device drivers from Linux to BSD (actual code )… I’m not convinced that that’s useful, but might be worth a look.

As followers of c.s.a. might have noticed I wrote down some of my thought regarding the Raspberry Pi port and what probably should be done to take advantage of the situation:

http://tinyurl.com/3sw4r6r

I can’t help with any of the actual porting but if I could be of any use, helping
with getting the documentation together etc, please do let me know!

(Posted here rather than RISC OS on the Raspberry Pi because it’s comment rather than actually related to getting anything done!)

There are some interesting comments at amiga.org.