RISC OS on the Raspberry Pi
Pages: 1 2 3 4 5 6 7 8 9 10 11 ... 17
patric aristide (434) 418 posts |
There currently appear to be several dicussions floating around regarding the Raspberry Pi. As has been suggested, I’d like to bring these together to a more central place. Hope that’s okay with everyone! Since this won’t be limited to the technical aspects of porting RISC OS to new hardware it’s probably better suited to this sub-forum. |
Trevor Johnson (329) 1645 posts |
Should some of the tasks Theo referred to be included on a new wiki page? e.g. Raspberry Pi Roadmap or similar |
Martin Hansen (393) 56 posts |
Porting Scratch to RISC OS for Raspberry Pi Dear All, I enjoyed your report about the 2011 RISC OS London show |
Rik Griffin (98) 264 posts |
It seems to be reasonably simple to get Scratch working in some way, although whether it’s useful or not is another matter, Download the Squeak archive from here and extract the !Squeak application to some convenient directory. Download Scratch for Windows from http://download.scratch.mit.edu/WinScratch1.4.zip and again extract the archive contents to some convenient directory. In the Scratch directory there is a file called Scratch/image. Set its file type to FAA (STimage). To start Scratch, double click Scratch/image. When it starts, it displays an error (inside the Squeak VM) saying a primitive has failed. More seriously, trying to open a file also gives an error. I’m not sure if this is due to the lack of plugin, or filename incompatibility or what … I’ve had a look at the plugin code – it’s in C but it looks like it should be compiled as a shared library under unix. There’s a plugin directory inside the Squeak application, but the files in there are not AOF executables. Whether you need some other Squeak based compiler or something to make a plug in, I am not sure. |
Martin Hansen (393) 56 posts |
Hi Rik, >> It seems to be reasonably simple to get Scratch working in some way, It seems to have quite a lively online community associated with it. Is Tim Rowledge still around ? Regards, |
Trevor Johnson (329) 1645 posts |
http://www.rowledge.org/tim/personal/cv.html
PS Martin, great idea submitting to OSnews in the first place :-) [Edit: (Moved from “Yet another potential RISC OS target?”) Under what license are our contributions made on this wiki?] |
Theo Markettos (89) 919 posts |
OK, before we get sidetracked into discussions of specific projects, can we start thinking about what needs to be done for a Raspberry Pi release: Kernel/ROM image
Disc image
Materials
Process control
Bold=essential, underline=important Those are just off the top of my head. No doubt I’ve omitted a hundred things, please follow up with other thoughts. I’ll wikify them as we go along. A few of the driver tasks can only be done by people with access to boards, the rest can be done by anyone. A couple of other comments. Linux RPi depends a lot on the SD card speed. RISC OS currently has very fast boot, because there’s no !Boot structure. I’m a bit concerned that the standard !Boot will make it slow again. So might be worth thinking how we can accelerate the boot sequence: either push more into ROM, or otherwise prevent lots of single-block reads from SD. FS caching, boot from ramdisk, rationalise the !Boot sequence, something else? On the documentation side, there’s an awful lot out there (eg hundreds of magazine articles) but it needs some substantial pulling together (and possibly tidying the obsolete stuff). Plus getting permissions that they can be published. In legal I include securing RISC OS licensing and checking the licences of everything that we distribute. If we can start working out what needs to be done, then we can prioritise what’s important for a release and what can be done later. |
Michael Drake (88) 336 posts |
How about Ethernet / networking? |
Chris Hall (132) 3554 posts |
The boot structure can be solved (at least initially) by using RAMdisk for the boot structure (see other thread). Then dependency on SD drivers for speed is removed. Cuts down 256Mbytes to about 180Mbytes for available RAM. Licensing so that a free copy can be bundled with Raspberry Pi is essential. Somehow we need to find a way of migrating any new users onto commercial licensing payments. But then new users will want bigger hardware where there is a margin for such payments. |
Chris Hall (132) 3554 posts |
Ethernet is said to be ‘ready to go’ as soon as the USB stack is working. |
Theo Markettos (89) 919 posts |
Ethernet comes ‘for free’. EtherUSB already supports the LAN9512 chip, so once USB is working Ethernet should work straight off (touch wood). RAMdisk for !Boot sounds like an idea – it needs some careful design so that writing to !Boot (installers, Choices$Write, etc) goes to the SD copy not the RAM copy. Post-boot rewrite of all Boot$ system variables, perhaps? Ideally a RAM disc cache would be slightly cleverer than just copying the files off the SD card (after all, that’s what !Boot does and it’s slow because there are lots of one-sector reads). So perhaps !Boot could be held in some kind of archive that can be grabbed wholesale, or the RAM disc could reconstruct a SD Filecore FS where blocks are allocated close together, or something else… |
Trevor Johnson (329) 1645 posts |
Kernel/ROM image
Disc image
Re: Educational software – Which publishers are still around? Over to you for priorities/strikethroughs. 1 No RTC with current versions. 2 I’m pretty sure some examples can be given, so will check this. |
Trevor Johnson (329) 1645 posts |
Is it quicker than the BeagleBoard? The default setup there waits 10secs for the user to intervene IIRC. Is there anything which could be usefully migrated from swiftbeagle? |
A.C.Daniel (376) 15 posts |
Two things spring to my mind which others may or may not find helpful. Firstly could the read only SparkFS help with speed of booting from the SD card? Secondly if it were available would the CacheFS module as used in the Bush Internet TV be any use for !Scrap so it doesn’t hammer the card or hog too much ram? |
Theo Markettos (89) 919 posts |
RTC is another big issue I hadn’t thought about. There’s no hardware on RPi for it (well, I have no idea if there’s a soft RTC on-chip but there’s no battery)… so I suppose NTP is the only way but that requires network. Perhaps default to 1/1/2012 not 1/1/1900? RISC OS on RPi with no disc is essentially instant, at least to the supervisor prompt. If there was CMOS RAM (ah, another thing that needs sorting) to hold the configured language (or it was hardcoded), autoboot into desktop would be <3 seconds I reckon. There’s no bootloader menu, the boot OS is determined by whatever is on the SD card. Swiftbeagle gives some useful general ideas (don’t fetch more disc than you need, compile things to be small, compress, etc) even though the specifics don’t apply. I’ve just created the roadmap wiki page that Trevor linked to with these ideas. At the moment I’m trying to be realistic – timescales are pretty short – so I’m trying to focus on necessary stuff rather than things that would be nice to have given an infinity of time and developers. For example suspend to disc is a really hard problem, and even Linux haven’t got it completely right, so I think doing it in 2 months is going to be impossible. Read only SparkFS might be interesting… I wonder if it does prefetch caching? CacheFS might be interesting for Scrap… but does Scrap get used enough to be a performance hit? |
Jeffrey Lee (213) 6048 posts |
How many RISC OS developers have access to boards, or at least hardware documentation? Because if it’s just Adrian (and he’s doing it in his spare time) then I suspect you’re expecting a bit too much out of him if you want the “essential” items to be done by Christmas (although he’s welcome to prove me wrong!) If the USB driver is based around the Linux sources then it’ll need a fair bit of poking in order to get it to work cleanly in RISC OS’s butchered NetBSD stack. The SD card driver (and the CMOS RAM code, assuming we go with the approach of saving to the SD card) will also need lots of hands-on time with a board in order to make sure that it’s working properly (or to get it working in the first place). Partition support won’t require access to a board, but if it’s going to be done properly then it’s a big task, hence why it’s on Sprow’s filesystem bounty list. Also, you might want to change your wiki link to this, as the link you’ve currently got takes you to the “create new page” page! |
Jess Hampshire (158) 865 posts |
Could it also be made to work properly read only? (i.e with external !scrap and !choices, configurable to be autocreated in the RAM disk). This would allow a complete working system with either no SD driver (!boot in resourses) or a read only driver. |
Trevor Johnson (329) 1645 posts |
Yes, some of the other things are really Wish List items.
"It deletes the older stuff" – is this true? (Maybe refuted later in the thread, but if so I’ve missed it.)
There should be 10 000 available by Christmas, but they’re not taking preorders so people will have to be quick! Probably following Raspberry Pi on Twitter is a good idea. (But if each of the currently approaching 5000 followers opts for the buy-one-give-one scheme does this mean they buy two each… or is it buying one for twice the price?)
It’s Step 2, and “just” Step 1 is a long way from being started. Therefore, some extremely wealthy donors are sought! |
Theo Markettos (89) 919 posts |
Adrian and I have access to boards. He’s working on the USB stuff, which he says will take him a while. SD card be prototyped on a Beagleboard (or indeed a PC laptop with the right sort of SD slot), if it’s written in a sufficiently portable manner – they all use the SDHCI standard – RPi specific tweaks can be sorted once the basic driver is working. In terms of initial-build supply, it’s possible we may be able to get access to a few boards from the initial batch that are held back for developers (no promises). But when the first batch is available I recommend piling into the queue anyway. I realise that full partition support is a bit optimistic, but some kind of support is required because a FAT partition is used by the bootloader. Perhaps an SD driver that parses the DOS partition table and picks the first FileCore partition? (Does FileCore even have a DOS partition ID? Or how else to recognise it?) Wiki link fixed :) |
Trevor Johnson (329) 1645 posts |
This post by trustee Jack Lang (who worked at Acorn) is probably worth noting. |
Jeffrey Lee (213) 6048 posts |
Ah, that’s good. I wasn’t sure how standardised the SD controller host interfaces were.
I think the safest bet would be to make the SD driver parse the partition table and look for a FileCore partition. That way you’ll be future-proof for when full partition support is added. FileCore currently doesn’t have a DOS partition ID (AFAIK!) so you’d have to invent one. |
Jess Hampshire (158) 865 posts |
This link might be useful: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html A while ago I asked the maintainer of the site what the procedure to register new types is. Apparently there isn’t one, and the best bet is to pick an unused one and email him to add it to the list. The Castle Storm SCSI card has some support for partitions, could ROOL perhaps see if Castle could add its sources to the RO 5 sources. (However from memory, I don’t think it created a filecore entry, it just created the first DOS partition at the end of it, which I don’t think is ideal) |
Trevor Johnson (329) 1645 posts |
Is it possible to save the time via CMOS (or via a custom file)? If the time were to be saved on shutdown (and, possibly, every hour too) this would be an enhancement over 1/1/2012 on next power-on. An (optional) boot-loaded app could then:
|
Theo Markettos (89) 919 posts |
They seem to be fairly secretive about the standard, but they can all be driven from the ‘sdhci’ driver in Linux so I think that’s a fairly good sign. The underlying transport mechanism might vary a bit (eg use of DMA) but that can be handled when most of the driver is written.
0xFC (‘FileCore’) seems to be taken, so maybe 0xACorn or 0xADfs… |
Matthew Phillips (473) 719 posts |
I’d be interested in helping build a list of apps and programming tools to be included. Would the best approach be to create a Wiki page pointed to from the one which Theo has created? We could build up a categorised list there, including links to the downloads, licence checking, compatibility checking, etc. How does that sound? |
Pages: 1 2 3 4 5 6 7 8 9 10 11 ... 17