Mequa wrote:I also noticed that RISC OS Pi is not currently compatible with Raspberry Pi 2
....
I am also wondering whether NutPi will be supported on a version of RISC OS Pi compatible with Raspberry Pi 2, given how this commercial RISC OS software was locked to the Raspberry Pi hardware.

jamesh wrote:Ref: Jazelle on Pi1, afaik, this is not enabled, and therefore unused. I think its a licensing issue rather than anything technical, but not sure.

James, thanks for this helpful information. So I think also for Java programs we can expect the Pi2's "usual" speed-improvments you and others mentioned in the FAQ and elsehwere. (If somebody wants to see the Mandelbrot demo in action which uses multi-cores, just download the JDK8 demo from Oracle and run it on the Pi. The Linux x86/x64 tar.gz works)

Can't wait to see a Pi2 in action. I admit it's as thrilling as when we got that 200 MHz StrongARM to replace the 30 MHz ARM610 in our Archimedes aka RiscPC computers.

Is the BCM2836 made with the same process as the 2835 (width, silicon, doping etc)? I'm curious as to how you've made it clock faster. I remember Dom saying the foundry had tweaked things in favour of speed at the expense of power consumption for the 2835 at the time of the B+ release. Is it more of that?

gregeric wrote:I asked this on the main page blog posting, but it's gone unanswered:

Is the BCM2836 made with the same process as the 2835 (width, silicon, doping etc)? I'm curious as to how you've made it clock faster. I remember Dom saying the foundry had tweaked things in favour of speed at the expense of power consumption for the 2835 at the time of the B+ release. Is it more of that?

It's the same 40nm process. Not sure of the other stuff.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

gregeric wrote:I asked this on the main page blog posting, but it's gone unanswered:

Is the BCM2836 made with the same process as the 2835 (width, silicon, doping etc)? I'm curious as to how you've made it clock faster. I remember Dom saying the foundry had tweaked things in favour of speed at the expense of power consumption for the 2835 at the time of the B+ release. Is it more of that?

BCM2836 uses the same process node as 2835 - 40nm low-power.

There are many factors other than the intrinsic speed of the silicon that affect maximum clock frequency - in particular, one problem is ohmic/inductive droop of the core voltage as it comes across the board from the bulk decoupling caps underneath the package, through the vias, on to the chip substrate and through the bond wires on to the chip.

Both chips have bond wires rather than flip-chip, but on 2836 you have a ridiculously large number of power/ground attached along the A7 cluster edge. This reduces your IR drop substantially which makes your volts less prone to bouncing at high power consumption. Dips in voltage as clock edges propagate across the chip is one of the reasons that cause a cap on clock speed.

Note that the ARM now uses the *uncached* bus access on BCM2836 (0xC0000000 bus alias). If you previously were computing memory addresses for DMA and incorporating the cached alias offset, this will break.

gregeric wrote:I asked this on the main page blog posting, but it's gone unanswered:

Is the BCM2836 made with the same process as the 2835 (width, silicon, doping etc)? I'm curious as to how you've made it clock faster. I remember Dom saying the foundry had tweaked things in favour of speed at the expense of power consumption for the 2835 at the time of the B+ release. Is it more of that?

BCM2836 uses the same process node as 2835 - 40nm low-power.

There are many factors other than the intrinsic speed of the silicon that affect maximum clock frequency - in particular, one problem is ohmic/inductive droop of the core voltage as it comes across the board from the bulk decoupling caps underneath the package, through the vias, on to the chip substrate and through the bond wires on to the chip.

Both chips have bond wires rather than flip-chip, but on 2836 you have a ridiculously large number of power/ground attached along the A7 cluster edge. This reduces your IR drop substantially which makes your volts less prone to bouncing at high power consumption. Dips in voltage as clock edges propagate across the chip is one of the reasons that cause a cap on clock speed.

Note that the ARM now uses the *uncached* bus access on BCM2836 (0xC0000000 bus alias). If you previously were computing memory addresses for DMA and incorporating the cached alias offset, this will break.

So I was interested in trying out RaspBMC on the RPi 2 (just received it today.) I haven't had any luck getting the RaspBMC sd card that I had running on a B+ to boot, even after the apt-get upgrade steps described above. So I went back to NOOBS, (got the latest revision 1.3.12), but NOOBS said it wouldn't install RaspBMC on the RPi 2. Actually, trying a few of the others, it looks like the only OS it will install from the NOOBS menu is Raspbian. Is this correct?

Anyway, anyone got XBMC running on Raspbian on the RPi2 so far? If so, what's the recommended installation path?

pico wrote:So I was interested in trying out RaspBMC on the RPi 2 (just received it today.) I haven't had any luck getting the RaspBMC sd card that I had running on a B+ to boot, even after the apt-get upgrade steps described above. So I went back to NOOBS, (got the latest revision 1.3.12), but NOOBS said it wouldn't install RaspBMC on the RPi 2. Actually, trying a few of the others, it looks like the only OS it will install from the NOOBS menu is Raspbian. Is this correct?

Anyway, anyone got XBMC running on Raspbian on the RPi2 so far? If so, what's the recommended installation path?

RaspBMC is not supported on the RPi2 - you'll need to move on to Sam's OSMC project as he has stated he will not be updating RaspBMC again.

abarnes1 wrote:So someone else mentioned that windows 10 may be a cut down version or have no GUI? Is it not possible to just install a regular copy of windows 10 on this thing onto a usb or the Micro SD?

Good question. Given that this "Windows 10" thing is turning out to be just a bad joke (for a variety of reasons), the relevant question is: Is the new Pi powerful enough (CPU, RAM) to run real (x86) Windows (not any version of this "10" abomination) effectively under some emulator (e.g., QEMU, etc) ?

That's the real question.

No. Given the 1.8-2x speed increase, we might expect to get an x86 emulation about equivalent to a 120MHz '486.

1GB of memory is not enough for any recent versions of Windows, and you'll only have a fraction of that available for an emulator.

Windows 95 may run fairly cleanly, but of course it wouldn't be licensable.

Obviously, there's not enough juice to run a "current" version of Windows. Obviously, that's not what I was talking about.

I was hoping for XP, but '98 would be fine. I'm sure many people have old, perfectly legal, copies of these older versions of Windows laying around.

The point is that a working version of '98 is far better than this crippled "Windows 10" that is being bandied about.

Remember, the top 5 reasons to run Windows:

The large body of existing, working, debugged (by, literally, billions of people worldwide) x86 software.

The large body of existing, working, debugged (by, literally, billions of people worldwide) x86 software.

The large body of existing, working, debugged (by, literally, billions of people worldwide) x86 software.

The large body of existing, working, debugged (by, literally, billions of people worldwide) x86 software.

A working, trusted GUI.

"Windows 10 on Pi2" has none of these.

And some folks need to stop being fanboys and see the forest behind the trees.