Psion Netbook Pro Port?

Has anyone considered whether a port to the Psion Netbook Pro could be done? This has 128MB Ram, 800×600 16-bit colour touchscreen, long battery life, nice keyboard, etc. The CPU is a 400MHz XScale PSA255. It also has 32MB of NAND flash, which could store RISC OS and some apps.

It also has SDIO, CF, and PCMCIA adapters (if there were drivers for these!)

I have one of these, and I know several people who have them too (and they are still available on ebay)

There is a Linux distro, with full source code available, for it too, which could help:

http://www.hpcfactor.com/forums/forums/thread-view.asp?tid=10543&start=181 (long thread, but eventually the ‘Psion LX’ sources and images are posted).

:)

Also, the netbook pro comes with its own bootloader, which may well make it easier to get RISC OS running. The bootloader can load files from compactflash cards installed on the device.

More info on the Netbook Pro:

http://linuxtogo.org/gowiki/NetbookPro

I worked on the Linux port. The sources floating around may well be the ones I provided when I sold mine 3 years ago.

I don’t think it’s the best target, if only because there are much better options now, or imminently available – the PXA255 is only in the RiscPC performance ballpark. Yes, there is some information available in terms of kernel sources, etc, but there’s also some not very well documented aspects of the system. It has a slightly unusual setup where it needs to cooperate very closely with another chip on board – almost a secondary processor.

Having said that, JWB did attempt a RISC OS port some years ago, but IIRC, was ultimately foiled by such issues. I don’t know if the results of such efforts are in the ROOL sources.

Remember also that it’s all very well for a suitable target to exist, but someone needs to spend a very substantial amount of time to make it work. I know that Jeffrey has made it look very easy, but he still has lots to do, and that was for a completely open system.

Certainly if I was looking for a new platform to port to, the NBP would be well down my list.

A HAL for the Psion Netbook 2 (I’m assuming it’s the same thing) is indeed amongst the pile of unreleased sources we have. However I also got the impression that John’s port had hit a brick wall. If anyone’s seriously interested in picking it up, I suggest they discuss the situation with John – if they still want to go ahead, I expect we could release the sources fairly easily.

How would I contact John (is that JWB?) – does he have a user on this site? I would be interested as to what the brick wall was, and whether the Psion LX source release at the end of 2007 would help in overcoming it? (that source release seems to work pretty well, using all the hardware except the SDIO card slot). I know that the BooST bootloader can get various Linux systems up and running, so it might be possible to boot RISC OS via that bootloader.

I have no native RISC OS hardware over here in NZ, but do have an Ubuntu system, and fairly fast RISC OS emulation installed. I’m going to set up a development system this weekend, then order the Tools CD from this site. I am also seriously looking at getting a Beagleboard to use as a dev system / proper ARM-based computer again!

I do of course have a Netbook Pro too (as do several of my family and friends after they saw my one!), so could use that to test the port too.

So, if anyone could point me in the direction of the correct John noting that ‘JMB’ and ‘john’ are users on here, then I will be happy to send them a mail!

The chap you want is John Ballance – CTO of Castle. There’s no facility to mail other registered users on this site, but a quick Google should show you an email address. Clue: he’s not your ex-Prime Minister. ;-)

I think the sources would be useful, if only because it’s another point of reference for how to support another platform, and as an example of what kind of information makes it hard/impossible to continue.

Also, in the perhaps unlikely event that someone else attempts a PXA255-based platform port, this would also be a starting point.

Hi!

I googled John Ballance, but can’t find a specific email address for him. I will just send an email to one of the general addresses at Castle (or Iyonix??) unless someone knows of a better way to contact him?

Thanks for your help!

I don’t know how often Castle email addresses are being checked these days. If you’re having no luck, try his initials @iyonix.com. Also, don’t let adverts for ways to save on your utility bills throw you off when googling for his personal email address…

I sent out to a general Iyonix address, and got a reply – I will send a more detailed one now – thanks for the help :)

I have just sent an email to John – I hope there is a way to get the sources for the HAL released :) (also I see from his email that he is JWB, which means he was the person who was doing the port I guess?)

Peter : You said earlier you worked on the Linux port for the Netbook Pro – I have seen three ports; one from Florian? (I think), I know there is an OpenPsion one too in an early stage, but there is also the Psion LX one which was meant to be installed on a 256MB Netbook Pro – is the Psion LX one the one that you worked on? Because I know the source code for that one was released just over a year ago.

Also – are there any issues in using Linux code as reference when developing a HAL? If so I would avoid that :)

Matthew

If all goes to plan, I will be getting some source code that will help me do this port (including source code for setting up the MMU and all the boot initialisation stuff etc) – so watch this space :)

Just in case you’re wondering, we haven’t forgotten – we’ll be putting the NetBook 2 HAL online when we’ve found time to process it properly – there’s some stuff in there that can’t be released which we’ll have to substitute, and it makes sense for us to release the matching Components and Products files at the same time, and these will also need some modification to work on the public CVS repository.

Also – are there any issues in using Linux code as reference when developing a HAL? If so I would avoid that :)

Ideally, it’s best if you don’t look at it at all. The GPL licence and Castle’s shared-source licence are mutually incompatible, and if you have never seen the Linux source code then you have a good defence against accusations of licence infringement. In this sort of situation, you’ll sometimes come across the process of clean-room reimplementation, where two teams of engineers work on a project, one team analysing a piece of software and writing a description of its operation, and another team implementing that description never having seen the original code.

That said, if you can’t or don’t wish to go to those extremes but wish to use Linux code as a reference – perhaps to help debug your own code – then there is some scope for doing so. Copyright law grants software authors certain rights over their work, and over derivative works, notably the ability to lay down conditions under which it may be used – and the software licence sets out those conditions. However, not everything is copyrightable: copyright does not protect ideas, only expressions of an idea. The distinction is a grey area and subject to the judgement of any court that might become involved, but it is clear that when there is only one way to express an idea then that expression is no longer protected by copyright law.

For example, if I write

#define PI 3.1415926535897932

(which is the least number of decimal digits needed to express an IEEE double-precision representation of π) then I can’t go accusing anyone else who uses the same thing in their own code of having violated my copyright, because it’s a mathematical truth and any other value would be wrong. However, if I accompanied it with an explanatory comment about how I derived the value, then the text of that comment would be protected.

This actually extends to all constants – so assuming that there are agreed register names for registers on a chip (for example because they are named in a published datasheet) then I believe you can legitimately copy a set of #defines of their addresses (though personally I have always re-entered them myself – I find it useful as a learning exercise).

I suspect this would also extend to things like the set of frequencies that PLLs have to be programmed to and in which order: these are mandated by external factors (the hardware) and so are unprotected.

However, if you find yourself tempted to copy data structures, choice of algorithms, or abstractions of data types or functional blocks, then don’t – these are still protected even if you change formatting or symbol names to attempt to cover your tracks. There are software analysis tools that will see through such tricks, and supporters of the GPL would love to take you to court to help set legal precedent.

If you want to find out more about what constitutes a derivative work, you could try googling for the Abstraction, Filtration Comparison (AFC) test, which appears to be in general use in both U.S. and English courts.

The usual disclaimer applies: IANAL.

Well, I haven’t looked at the Linux code yet (don’t have the hardware setup code, which has (as yet) never been released online). I will ensure I don’t break the GPL etc when I get started :)

Is there any progress on this front? I still have a regular netBook lying around but this netbook pro seems to be an entirely different beast.

The netbook has a StrongARM, and I think it is more ‘open’ than the Netbook pro. (at least, more info is around as they were available to the public)

I haven’t done any more work on the Netbook Pro (waiting for Netbook Pro HAL to be released), but I do note that the bootloader sets up the screen and prints stuff on the screen, and can read the keyboard, implying that a significant amount of the hardware would already be set up before RISC OS took over.

Also, the display in the Netbook Pro can do 8-bit palette-based display modes as well as 16-bit ones in hardware, meaning a wider range of display modes would be available to RISC OS.

I’m trying to get a working serial cable so I can start messing around with the bootloader using serial output; then I could see if I can get some code booting on the system – could then start to try with RISC OS!

The Netbook Pro HAL would be great if it was released, though! Although not the newest machine, a 400MHz 800×600 Risc PC portable with very good build quality and battery life would be a good thing, particularly as I (and a few people I know) already have a Netbook Pro!

(and they are still available on ebay)

They seem to go for around 90USD, or less in bulk .

BooST bootloader

There’s a bit of info on Paul Vigay’s Psion resources page .

I have two PXA270 devices that could really use RISC OS. The PXA255 is similar to the PXA270 so I guess I would like to see the state of the HAL port for the netbook.

Possibly the best way would be to start a HAL from scratch by using the OMAP HAL as a reference.

Any other suggestions?

• I really want the Netbook Pro HAL! *

I hope it can be released soon :)

For what it is worth, I have got the binary of the BooSt file used to boot Linux. There is a piece of code which sets up the Netbook Pro, prior to handing over the control of the computer to the Linux kernel.

This has been reverse engineered, using !Zap on RISC OS, and a high-level description has been created. From this, I have created a homebrew bootstrap code, and now have a BASIC file which compiles this code, and links a Kernel file (Linux kernel, but could also be RISC OS), and an initrd file. Currently it doesn’t work, but that is only a minor issue – there will undoubtedly be a few bugs, and I think I set the bit in BooSt that resets the hardware anyway!

The Netbook Pro has a ‘PCON’ chip (peripheral controller). This is a 16-bit Mitsubishi Microcontroller, and is used to control the Keyboard and many other peripherals.

I believe this is the same chip that the bootstrap code communicates with at a low-level at the start, before handing control over to the Linux Kernel. The bootstrap code switches off the PXA255 MMU, prior to issuing a serious of commands by writing one byte at a time to memory-mapped IO (the commands are not completely clear, but which appear to be doing some kind of memory setup). Once the kernel gains control of the PXA255, the MMU gets switched back on, and no further commands are issued using the byte-at-a-time format. Essentially, it is likely that, once a working bootloader is made, it should be relatively easy to load whichever kernel is required.

Over the next while I will get the bootloader working (it will be open-source), and see if I can boot a known-working linux kernel. If so, it might be easier than originally thought to get RISC OS running :)

Keep up the good work tymaja *a little motivation never hurts ;)

Thanks :)

The netbook pro hal has been released by ROOL.

Great! tymaja – you must be itching to be able to update those “not functional yet” notes!

Just checked and there’s one currently on ebay (located in the US) – if anyone else is interested by this. It’s a buy it now for $75 but with postage that must be more like £80. Comes with charger, battery and stylus – dunno if that’s everything from new. Auction ends just before 5am this Sunday.

Progress report…..

The bootloader, which is the first place where you need to do communications with the onboard second CPU (PCon), has been fully reverese engineered and rewritten by myself (from a high-level description) :) I currently have a custom bootloader that boots a known-working Linux kernel. My bootloader also initialises the screen, and loads a splash-screen. This is important, as it means RISC OS will inherit a ‘clean’ system but with framebuffer already initialised!

In April, my Netbook Pro broke (a small PC screw got into the case, and shorted the charging / battery circuit), so development has been halted till I got my ‘New’ secondhand NB Pro 2 weeks ago.

Now, I just need to order myself a copy of the compiler from riscosopen.org, and get to work :)

One issue I know – I haven’t looked at the files themselves, but… I am aware that the Netbook Pro keyboard is driven by the Psion PCON. (Which is a Mitsubishi 16-bit single-chip computer with 128K of custom firmware). What this does / how to interface to it is a secret very closely guarded by Psion, except for the fact that their source code for a working Linux kernel was ‘leaked’ onto the internet. They did release a set of commercial NB Pros with Linux to the NHS, meaning that, technically, they should have released their source code for the kernel anyway!

There will be absolutely no way whatsoever to obtain information on how to drive the keyboard (or power management) without looking at the Linux sources. I myself have deliberately not looked at these particular sources, although have compiled them – and they do work!. Is there a way that these sources can be used to make a version of RISC OS for the NB Pro? If so, how should this be done to avoid cross-contaminating the licenses between Linux and RISC OS? Would it be enough to keep the keyboard and power management code in a seperate file, with the RISC OS keyboard / power management files calling routines in the Linux-derived files? Would this mean that whatever changes I make to the Linux files are GPL’d, whereas whatever changes I make to the RISC OS files remain under the Castle license?

I could always get someone to write a low/high-level description of the keyboard routine in particular, but actually finding someone to do this would be a problem! Then I could re-code from there. However, is the approach describe above also viable legally?