Raspberry Pi Model B+

The nightly beta development build zip is from 2014-07-16 06:43:02, but the rom inside still has version (04-jul-14). The LanManFS is still at 2.45, DWCDriver is still at 0.15, DragASprite is still at 0.18, so it looks like there is something wrong.

The nightly beta development build zip is from 2014-07-16 06:43:02, but the rom inside still has version (04-jul-14).

That download is as it should be here. (On Raspberry Pi B (no +))

Beta RPi ROM  2014-07-16 06:43:02

*fx0
RISC OS 5.21 (16 Jul 2014)

LanManFS     2.46 (14 Jul 2014)
DWCDriver    0.16 (08 Jul 2014)
DragASprite  0.19 (05 Jul 2014)

That download is as it should be here.

And here. The ROM version inside the RC12a SD card image is 5.21 (04-Jun-2014) with LANMANFS 2.44 etc. though. Surely it is time that the ROM image for the Raspberry Pi was ‘stable’ now?

Still throwing logs on the fire….
I downloaded a fresh BCM2835DEV tarball and built from that. Still no luck on the B+.
So something must have changed that has not fed back to the repo yet….

Chris/David, found it, a bug in Fat32fs, not my new riscos.img but the old renamed rom had the 8.3 dos-name RISCOS.IMG.

I downloaded a fresh BCM2835DEV tarball and built from that. Still no luck on the B+.
So something must have changed that has not fed back to the repo yet….

You do have the updated firmware don’t you? You need it on the Model B+.

.BOOTCODE/BIN     WR/     DOS       21:29:00 04-Jun-2014   17 kbytes
.CONFIG/TXT       WR/     Text      14:25:06 31-Jan-2014   76  bytes
.FIXUP/DAT        WR/     DOS       21:29:00 04-Jun-2014    6 kbytes
.LICENCE/BROADCOM WR/     DOS       14:47:06 10-May-2012 1447  bytes
.RISCOS/IMG       WR/     DOS       23:25:48 04-Jun-2014    5 Mbytes
.START/ELF        WR/     DOS       21:29:00 04-Jun-2014 2494 kbytes

Bootcode.bin, Start.elf and Fixup.dat have all changed.

.RISCOS/IMG WR/ DOS 23:25:48 04-Jun-2014 5 Mbytes

Mmm 5MB I wonder why that is not compressed?
A nightly build or from rc12a?

That is what is inside the RC12a SD card image. Uncompressed ROM.

From the Pi Forums:
“The default current limit setting for the USB ports is 600mA (aggregate across the 4 ports). This can be increased to 1.2A via software config if you have a sufficiently powerful PSU.”

How you configure it I do not know! I’ve asked on the Pi Forum.

The answer from:
http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=81736&p=580528#p580528 &
https://projects.drogon.net/testing-setting-the-usb-current-limiter-on-the-raspberry-pi-b/

The first way is via a new option in /boot/config.txt. Currently you can add:
safe_mode_gpio=4
but note that this will become:
max_usb_current=1
in subsequent updates.

Both require a reboot of your Pi.
What date of firmware you need I don’t know.

Hi all
I’ve just got my B+.
Dumb question (since you all seem to be up and away with your B+s and I can’t find reference to this anywhere on the site) but does the micro-SD card have to be dual format as on the B?

Or can just the firmware be on the micro-SD and boot sequence on another, ADFS medium e.g. memory stick (like the Beagleboard)?

If so how?

thanks :)
Chris.

Nothing has changes apart from the SD drive shrinking to microSD.
If you want your boot drive with $.!Boot on it to be the microSD card them it need to be dual format.

You can have your boot drive on other medium like a BeagleBoard but the SD drive is the quickest media¹ on a Pi.

¹ as SDFS & SCSIFS don’t yet have caching, FAT32FS devices can be faster under some circumstances but the SD interfaces has the fastest hardware.

as SDFS & SCSIFS don’t yet have caching

I’ve seen that mentioned as a possible silver bullet a few times but remain unconvinced it’ll be such a step change.

FileCore’s buffering is all based on speculatively reading to C/H/S boundaries within a fragment, but
with a miserly 255k buffer, to help with spinning drives and floppies in particular so you don’t have to wait for the media to come round again to get the next sector or two. As a point of reference the last drive I fitted to my brother in law’s PC was a 512GB drive with on board 32MB of cache – 128 times bigger than FileCore’s.

With SCSIFS and SDFS a large proportion of use is with solid state media (USB sticks/SD cards/SSD) where there’s practically 0 random seek time – though spinning harddiscs in USB caddies would still benefit.

The write behind buffering does decouple the foreground from having to wait for the IO to complete, but again a 255k buffer is probably getting quite easily filled.

It’d be interesting to instrument up either SDFS or SCSIFS to try to get a guess at what improvement might be had for something that gives the drive a good workout (a ROM build, email debatching, that sort of thing) as that’ll probably be less effort than trying to add background transfers to either of them only to discover that it doesn’t help much.

I’ve seen that mentioned as a possible silver bullet a few times but remain unconvinced it’ll be such a step change.

Well I’m basing the comment on information from Ben, but I may extrapolating more from it than warranted! Apart from mentioning the ‘no caching’ Ben said that the SD bus on the Pi is significantly faster than on OMAP. I think I’ve seen numerous mentions that the SD BUS is faster than the USB bus.

I expect (as you say) FAT32FS is faster than SCSIFS or SDFS in software terms but I would hope that they all can drive the hardware close to its maximum when a large file is written or read and the faster hardware of the SD bus would compensate for the slower FS.

The benchmark programs seem to show a massive slow down for SDFS and SCSIFS over FAT32FS (Even on the same hardware) I suspect some of the test results would significantly change with caching. But as few RISC OS programs do much file manipulation it probably won’t make much difference to the user experience!

I think the point that Sprow is making is that FileCore’s current caching implementation is likely to be insufficient for most modern use cases. So apart from taking a look into SDFS and SCSIFS to see if there are any latent performance bottlenecks (e.g. I suspect we aren’t getting full performance out of USB) we should also be looking into writing a new caching layer for FileCore (or the filing system stack as a whole). Modern machines have hundreds of megabytes of memory sat around in the free pool just doing nothing, we should be doing what Linux, Windows, etc. has been doing for years and using that as our cache for disc ops. And ideally that cache memory should be usable by anything else that needs it (font cache, image cache for browsers, etc.)

One thing that strikes me is that the whole I/O layer may benefit from a re-write. It would be nice if we could make it more POSIX compliant, providing open as well as fopen. Caching is all well and good, but there are certain operations that you don’t want caching at all (databases etc). Adding an I/O scheduler would be great as well, but then we need to take into account the underlying hardware (i.e. is it an SDCard, SSD, hard disc).
Then of course there is the question of 64bit ARM chips, BIG-little, multi-core support and the age old debate of pre-emption.
If I were to suggest a course, it would be to look at doing the whole lot in a new fork of RISC OS.
The 64bit chips support some kind of virtualisation, which could mean the “old” 32bit applications could run under their own OS.
It looks like 32bit ARM is set to be legacy in a couple of years.
Whether that is viable, sensible or worth while is another question!
But it would certainly be “fun” ;-)
Another question would be is it worth reworking the current OS, given it’s current application estate?

I’m not answering these questions as I’m not in a position to do so from either a technical (as I may know a little about RISC OS, but that’s about it)
or from a marketing point of view (i.e. if the OS was re-written, would it attract enough new people to the OS to give it a new lease of life)

My personal view is that it would be beneficial – but I do have rose tinted glasses and tend to try and avoid reality as much as I can ;-)

The cool thing would be a ‘shadow cache’ (or – if you prefer – a free memory manager). Something that use automatically all free memory, without blocking it, and with a list of pages not available anymore (ie new allocations for apps or modules). It would be good for read only needs (images, fonts, disc data). Perhaps not very fast, but cool :)

(Sorry if it’s not very clear. It’s in my head).

Modern machines have hundreds of megabytes of memory sat around in the free pool just doing nothing, we should be doing what Linux, Windows, etc. has been doing for years and using that as our cache for disc ops.

If the plan is to consider a large cache, please please please plan from the outset to either disable caching, or switch it to read-only caching.

I say this because I live rural. Little towns expanding due to “lottissement” houses (generic monopoly piece new-build houses) and an electricity infrastructure that just isn’t keeping pace with all of this. From time to time we get power cuts, a little more than a brownout but not long enough to be a problem to living. But certainly long enough to have every electrical device that doesn’t have a battery onboard to reboot.

It seems to me that FileCore formats do not always cope “gracefully” with incomplete writes to disc (“One copy of map broken”…), there is no journalling, and to have many megabytes of cached data for writing just seems like the potential for a huge accident waiting to happen.

Right now with NetSurf and the DDE and my server running, I have 185Mb free on a 256Mb(32MbGPU) system, so it makes sense to think of using it as a cache. However, if the time should come that it does so – I’d prefer to manually disable write caching and just accept the speed hit that it would cause.

Thinking, also, when would the data be written to disc? You can’t access FileCore on a CallAfter (unless some re-entrancy-safe hooks are provided) and if the machine crashes, we’re not guaranteed to ever see a CallBack. Does this leave the data in limbo?

One thing that strikes me is that the whole I/O layer may benefit from a re-write.

Probably, yes. We ought to have some idea of “stuff happens in the background”. Problem is, who is going to do this? And how much munging will be necessary to not break older software?

It would be nice if we could make it more POSIX compliant,

Oh. God.

Full POSIX is an IEEE standard (probably costs $$$$ to certify) and it describes a command line and script system based upon the Korn shell, services and utilities (what must be present and their command line options), the structure of the filesystem, a threading library, and a bunch of library things.
Basically, it is a “Unix” system encapsulated in a technical standard.

It is worth pointing out that Linux, Haiku, Minix, NetBSD, and FreeBSD are not fully POSIX compliant (mainly due to extensions and “POSIX sucks, we think this is better” implementations).

providing open as well as fopen.

Why?

Both open files. Neither open files using the native RISC OS mechanisms. I use DeskLib’s File_Open() :-)

Caching is all well and good, but there are certain operations that you don’t want caching at all (databases etc).

There are certain operations where a large cache would be hugely beneficial (databases etc).

[experience: DOS version of FoxPro with and without a cache manager that used XMS talking to a fairly slow early-IDE harddisc]

It looks like 32bit ARM is set to be legacy in a couple of years.

I’m not sure I’d agree with this. 64 bit is great for high end systems and servers, it might well be overkill for mobile phones, and I wonder how many domestic printers are using Thumb² as the simpler hardware design is worth it?

Another question would be is it worth reworking the current OS, given it’s current application estate?

The answer I prefer is that it is mostly being done as a labour of love. To stand as a beacon of coding efficiency against the ever-increasing inefficiencies and bloatware of other systems. Plus it stands as one of the few open source operating systems with the insides written in assembler. In this day and age, that’s astonishing, but it gives a system that is simple and efficient and responsive.
This isn’t to say that there are no problems, this thread is referring to a slowness of file operations and elsewhere I’ve been taking a hatchet to Territory ;-) – however there are many good things too. RISC OS is an increasingly unique user experience, and maybe those few people that work on the code do this because they recognise such things.

My personal opinion is that while threads and such may be of assistance if supported at kernel level, if you want POSIX, install some flavour of Unix.

if the OS was re-written, would it attract enough new people to the OS to give it a new lease of life

Uh… One does not just “write an OS”.

If you want an example – look at MINIX. It is a Unix-like OS with some brilliant experimental features and a hugely detailed book to go with the source code. I got it out of Woking library ages ago and learned quite a bit about how operating systems are put together.

It is now up to MINIX3 with more features… but it appears to still be tied to x86 hardware and still stuck in the world of academia.
Maybe Torvalds has a bigger [mouth|ego] than Tanenbaum? I don’t know. It’s just that one new Unix-like OS is vastly popular, and this one, less so.
http://www.minix3.org/

and tend to try and avoid reality as much as I can ;-)

Best thing, I think. :-)

Thinking, also, when would the data be written to disc? You can’t access FileCore on a CallAfter (unless some re-entrancy-safe hooks are provided) and if the machine crashes, we’re not guaranteed to ever see a CallBack. Does this leave the data in limbo?

AIUI FileCore currently only deals with write caching for files, and it does so on a per-file basis, which seems perfectly sensible considering the problems you can get yourself into with excessive write caching on non-journalling filesystems (consider FAT on Windows). There are also well-defined mechanisms through which the cache can be flushed (OS_Args 255, fflush, closing the file, etc). So as long as any new caching system continues to honour those interfaces then the risk of data loss shouldn’t be any greater than it is now.

Well I’m basing the comment on information from Ben, but I may extrapolating more from it than warranted!

I do expect background transfers in SCSIFS and SDFS to speed things up – it certainly ought to because RAM is the fastest store available (after the on chip cache of course). My words of caution are to do some benchmarking first before embarking on implementing it since the gains might only come out in 10’s % not factors of 2!

Does this leave the data in limbo?

AIUI FileCore currently only deals with write caching for files, and it does so on a per-file basis

The speculative read ahead/write behind is only applied to things using the byte read/byte write interfaces (OS_GBPB, OS_BGet, OS_BPut) any whole file operations (OS_File) don’t go that way as clearly any file bigger than the cache size would just evict everything in the cache, while wasting time copying it twice in memory.

Additionally, when FileCore is being used for image files (eg. DOSFS) none of that gets read ahead/write behind-ed either, because the scheme requires FileCore to know what C-H-S fragments of files correspond to which it clearly doesn’t for foreign images.

Of course FileSwitch buffers stuff for OS_GBPB. OS_BGet, OS_BPut too, so often you’re paddling around in its sector sized buffers. FileCore only kicks in when the file pointer spills outside FileSwitch’s buffer.

Write cache should be small anyway. Read cache is the most important part. And can be loosed anytime… so my idea to use free memory and let applications overwrite some part of the cache. I’m not on system things, but is it possible to read/write any part of the system memory from an application/module? Is there a simple way to know if some part of the RAM is used by a module/app/stack?

My idea is to say: if it’s not used, use it as a page for cache, without allocate it (for the system, it’s still free memory). If it’s used later (when you try to read the page), simply consider that the page is lost. Need also a mechanism to add released RAM to the map of free/available RAM. The good point is that the system could continue to allocate RAM as usual, with no need to manage the cache (managed by the cache manager itself).

Stupid idea?

@Rick I pretty much agree with you on most of what you say.
I didn’t mean make RISC OS posix compliant, just a little bit more – or adding the missing functionality.
As regards fopen/open the difference is open writes directly to disk, I’ll definately be looking into the inards of file operations then, cheers for the pointer.
From what your saying, maybe it’s just a case of writing libraries/knowing which libraries to use, rather than anything else and me making assumptions that are clearly false.
Cor, I remember FoxPRO – although calling it a database is possibly pushing it ;-)
Databases should IMHO maintain their own cache, as they far outperform any filesystem cache.
I wasn’t implying “simply” rewrite the OS that’s going beyond even my streched reality.
I just think adding cache functionality, in reality isn’t going to bring any benefit on it’s own. Or more specifically I haven’t seen anything that would bring any benefit to RISC OS that simply supporting a nice SATA disc (which have as far as RISC OS goes a huge cache, 64-256MB of cache) wouldn’t do and using something like Memphis for !Scrap.
Unless there are other usage ideas for RISC OS that I’m not aware of, which is entirely possible.
As regards 64 bit, I agree that for mobile phones its overkill. However that doesn’t alter the way the future seems to be looking at the moment – of course 4 cores is 4 times faster than one – the same reason formula one cars have eight engines….oh wait that’s just marketing ****
Whilst there will probably be 32bit arm SoC’s for a long time, dismantling a printer to run RISC OS isn’t going to be fun! [I’m being silly, of course it would be!]

I agree – the OMAP5 has a SATA port and I would say that getting that to work correctly under RISC OS is a much higher priority than a more generalised cache.

My words of caution are to do some benchmarking first before embarking on implementing it since the gains might only come out in 10’s % not factors of 2!

It does sound like efforts in other areas may be a lot more fruitful! Chasing benchmarks is a fools game especially when RISC OS spends very little time actually reading or writing and they do not represent how users actually use their computer.

My B+ and NOOBS arrived today, just in time to test my new 40 pin interface. One strange thing though. The first thing I always do with a new version of RiscOs is to turn off textured window background. Nowhere could I find a button to do this.

Am I overlooking something obvious? The OS reports itself as 5.21, 4 Jun 14

Jochen