Raspberry Pi 2

A photograph leaked out recently (a link was posted to comp.sys.raspberry-pi), but the Raspberry Pi 2 has been officially launched today.

Its physical dimensions are the same as the B+ (so it doesn’t affect the RiscPiC case designs – if you ignore the certain little points¹), but the big change is the switch from a BCM2835 to a BCM2836. I can’t find that on Broadcom’s site, but according to the Raspberry Pi post above it’s a 900MHz quad-core ARM Cortex-A7 (i.e. it’s ARM-v7 rather than ARM-v6). The post says that’s the only difference between the BCM2835 and BCM2836.

Presumably, the existing Pi RISC OS image will therefore just work?

¹ I haven’t updated the -mini case from the one I had at London: That warps noticeably when the B+ is inserted (so I’ve been declaring it B only), but I’m not going to change it until the last few are gone. As for the -standard, I still haven’t got it to fit together correctly. :(

The way Ebon has described it it sounds like existing stuff should just work, although presumably just benefiting from the extra MHZ and ram for now; ARMv7 and the extra three cores will need a bit of work I would guess!

Presumably, the existing Pi RISC OS image will therefore just work?

Presumably not, Linux will need a different kernel and firmware on Raspberry Pi 2. So most likely RISC OS too.

I suspect at least a couple of tweaks will be needed to the ROM to get it to work. Possibly ROOL have already made those tweaks, since we know they are buddies with the Pi foundation. If not then it shouldn’t take too long for me to get it up and running (once my board arrives, that is).

Of course the fact that it’s now ARMv7 instead of ARMv6 means that the ARMv5 compatibility mode won’t work anymore – so people wanting to upgrade to the new model would be wise to make sure they aren’t using any software which relies on ARMv5 mode.

From www.raspberrypi.org: “For the last six months we’ve been working closely with Microsoft to bring the forthcoming Windows 10 to Raspberry Pi 2”

Does anyone else find this direction worrying? What does this mean for people who would otherwise be turned onto RISC OS? Is this just an extension of the mentality that goes “lets not write good software, lets get fast hardware so we can forget about how slow/badly written the software is”?

I should be excited about the new development so why does it make me feel suspicious/wary/a little bit sad?

“lets not write good software, lets get fast hardware so we can forget about how slow/badly written the software is”

You’ll let us know when Impression X¹ is up and running on the new hardware…?

¹ Or any other “tightly-coded” RISC OS software title from those halcyon days.

Ha touché!

I wasn’t talking about RISC OS specifically but I’m coming from the PC world where every year you feel obliged to buy the latest and greatest processor just to keep the OS happy (let alone any other software).

My desktop runs 8 cores at 5GHz but doesn’t feel as responsive as RISC OS on a 700Mhz Raspberry Pi…so where is all that extra power being used…?

Recently at work we were archiving a lot of old equipment and came across a 286 running Windows 3.1 – as part of the project I had to make sure that all the equipment still worked so I turned it on (amid a gathering of curious geeks from the office). The general response was “wow, that was quick”.

OK I know that software today is massively more complicated, but hardware is massively faster as well…sometimes I feel that we’ve missed a trick somewhere along the line and are locked into a crazy game of leapfrog.

Please don’t get me confused though – I’m not a Windows-bashing zealot – I do use Windows and do believe it has something to offer – but also feel that there is room for diversity in computing which may be getting eroded if Windows is available for the Pi. People have been locked into a mindset of “I need a computer, therefore I need Windows” without appreciating the diversity of options that are available.

Sometimes Windows is the best option (one of our HTPCs runs Windows 8.1). Sometimes it is not (the older HTPC works better with Linux). My only concern with the news that the new Pi will support Windows is that education authorities, maker communities, etc., that may have previously promoted the Pi with NOOBS (that contains Raspbian as well as RISC OS) will switch to the Pi with Windows because “I need a computer, therefore I need Windows”.

I suspect at least a couple of tweaks will be needed to the ROM to get it to work. Possibly ROOL have already made those tweaks,

I see some Pi2-related changes have appeared in CVS just now.

The thing is, Windows for ARM isn’t actually that useful, look at how RT flopped.

Also, your 8-core 5 GHz machine not being responsive… I’m assuming that’s because it’s running AMD? There’s your problem, when a quad core Intel processor from 3 years ago is faster. And, Windows and other modern OSes simply do a lot more, and yes, there’s less of a focus on tight code because hardware is cheaper than paying programmers.

In any case, I’d think this makes RISC OS multicore support quite a bit more important?

I suspect at least a couple of tweaks will be needed to the ROM to get it to work. Possibly ROOL have already made those tweaks,

I see some Pi2-related changes have appeared in CVS just now.

Ah, excellent.

I didn’t realise the Cortex-A7 had VFPv4 and NEONv2 – I think I have to extend VFPSupport to support those properly. But with Ben’s changes now in I’m guessing that’s the only thing left that needs fixing.

not being responsive

I would not describe it as “unresponsive”, just does not feel “snappy”.

I’m assuming that’s because it’s running AMD

I have used recent Intel processors at work and notice no real-world differences in terms of performance, what I would say though is that Linux on the AMD chip seems slightly ahead of Windows (although I haven’t had Windows on there since it was new so AMD might have some better Windows drivers now?). What I did notice when I first booted up RISC OS was how responsive it was on the Pi. Perhaps its better to say that I hadn’t noticed the “slowness” of my Windows (Intel) and Linux (AMD) computers until I had used RISC OS on the Pi? (“slowness” being a relative term of course because they are in no means “slow”).

I should qualify these statements by saying that my work involves writing cross-platform GUI programs, so even as a programmer, I do get irked by how slow things are running sometimes (is it me? Is it the compiler? Is it the framework? Is it the OS?). I can optimise my own code but sometimes feel like I’m banging my head against a wall…

hardware is cheaper than paying programmers

Don’t I know it!

But there is also a trend for programming by drag-and-drop GUI tools and getting non-programmers to do the work at half the price. I’ve lost count of the hours I’ve wasted trying to debug something that has been “written” using a drag-and-drop approach.

Although I admit that maybe I’m just a little bitter about having to use WPF and XAML…

In any case, I’d think this makes RISC OS multicore support quite a bit more important?

Agree with you absolutely and (cue sound of a can of worms being opened) what about PMT for these cores?

I’m a little bit sad to see Win10 for the Pi, however this in itself is quite a statement given the number of boards that have come and gone with little interest from anybody…

Personally I think that x86 is “slow” because it burns a lot of energy and time translating the horrible x86 instruction set to something the processor can actually execute. Just because the processor is clocking xGHz doesn’t mean it will be doing an instruction per cycle. The order scheduling and prediction and pipeline are insane…

If only the core has been changed, does this mean the IIC, USB, etc bugs haven’t been fixed?

I’m a little bit sad to see Win10 for the Pi, however this in itself is quite a statement given the number of boards that have come and gone with little interest from anybody…

After my lunchtime walk, coffee and far too many jelly sweets I have changed my mind. Maybe its good that Windows comes to the Pi because maybe its time for the world to be weaned off x86? If Windows is working on ARMv7, Linux is working on ARMv7 and RISC OS is native to ARMv7, maybe it will help with cross-platform programming? Maybe the scared-would-be-pi-programmer can be enticed in with a bit of Windows and then convinced that RISC OS is a good alternative? (Maybe I should stop eating so much sugar?)

If only the core has been changed, does this mean the IIC, USB, etc bugs haven’t been fixed?

From what I’ve been reading its practically a drop-in replacement for the chip in the “Model 1 B+” that Broadcom and the Pi Foundation have designed together so I guess any other bugs will remain…

As far as I’m aware, this is NOT ordinary Windows 10—it appears to be a version aimed at the maker community and “Internet of things” projects. I also suspect there will bot be many application program’s available for it.

The poor performance of Windows on the chip night even create some extra converts! From a RISC OS point of view, however, the performance gains for Linux—which CAN make use of the extra cores—should be significantly more than for RO, depending on the application being run.

That said, I’m also a little sad that an organisation which promotes open-source software has been working with Microsoft to bring Windows to the Pi 2 :-(

once my board arrives, that is.

I ordered mine from CPC just before posting here – it was only after I’d ordered it that I suddenly thought about whether or not RISC OS would actually work.

My initial thinking was that since everything else about it is apparently unchanged, with only the processor itself changing, the only issue would be the instruction set – and since we already have ARMv7 targets (and the old processor in the Pi could run ARMv7 code) I wondered if the existing Pi version was compiled for ARMv7. And if it was, then it seemed possible that it’d just work.

If not, I’ll just have to wait until it does – which might be the case by the time it arrives anyway. :)

Aside… the Windows 10 thing makes me wish I hadn’t posted this three years ago. It’d be funnier to do it this year.

I ordered mine from CPC just before posting here – it was only after I’d ordered it that I suddenly thought about whether or not RISC OS would actually work.

There are (today) some CVS changes for Pi model 2.

Farnell are waiting for stock. RS have accepted my order.

Farnell are waiting for stock.

My order status currently says “Complete” which they define as “Your order has been processed and shipped.”

According to the article on El Reg there were to be 100,000 units available straight away – so presumably, whatever portion of that lot were with CPC Farnell is already gone. Impressive.

If only RISC OS stuff sold that quickly… ;)

Out of curiosity, though, I’ve just gone through as though to buy another – it’s not claiming to be out of stock here.

Edit: Ah, okay. I suspect you were trying to get it from uk.farnell.com – I ordered mine from cpc.farnell.com; same company but different trading divisions, (I think…) operating from different locations

RS say that mine has been shipped and should be here tomorrow.

We will have stock of Raspberry Pi 2 at the South West Show!

I’m just trying to figure out how to add support for this in ADFFS. Does anyone know if ARMv7 (or this flavour of it) can be made to Abort on unaligned loads?

Does anyone know if ARMv7 (or this flavour of it) can be made to Abort on unaligned loads?

Yes, all ARMv7’s can be made to abort on unaligned loads – that’s the default behaviour RISC OS uses.

The ARMv7 compatibility primer might be worth a look, because there’s more than just the unaligned load behaviour which will now be causing you problems (e.g. MOV pc,xx now performs an interworking branch).

(Insert standard message here about how crazy you are and how much easier things would be if you just did full system emulation like ArcEm)

I didn’t realise the Cortex-A7 had VFPv4 and NEONv2

Yes, and it has hardware integer divide as well. It makes sense when you realise the Cortex-A7 is used alongside Cortex-A15 in big.LITTLE designs – the same binaries have to be able to work on both because (as I understand it) threads can be moved from one type of core to the other at runtime.

Just to confirm, although future releases of both RISC OS and other existing Raspberry Pi OSes like Raspbian will run on both Pi 1 and Pi 2, the old releases won’t – both the operating systems and firmware will need updating.

Yes, all ARMv7’s can be made to abort on unaligned loads – that’s the default behaviour RISC OS uses.

I’ve learnt never to assume anything where ARM are concerned, they love to drop features or make them vendor optional! I might look at making ADFFS’ JIT fully ARMv7 compatible then.

The ARMv7 compatibility primer might be worth a look, because there’s more than just the unaligned load behaviour which will now be causing you problems (e.g. MOV pc,xx now performs an interworking branch).

Easy enough to solve, it just needs a BIC in the PC altering codelets. Thanks for pointing this out, I hadn’t even considered it.

(Insert standard message here about how crazy you are and how much easier things would be if you just did full system emulation like ArcEm)

Where’s the fun in that ;) I wouldn’t be here if it was an easy challenge. ADFFS’ JIT runs code at around 90% of the hosts raw speed, how many emulators get full ARM3 speed, let alone anywhere near StrongARM? I’m rather proud of what I’ve achieved to date :)

Anyhow, back on subject. Is RISCOS, apps and !Boot all now fully ARMv7 compatible? I guess it has to be to release a Pi 2 ROM.