The Raspberry Pi 2 Q&A thread

[arm2]

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.

The latest nightly Beta of RISC OS is working here on my Pi 2 https://www.riscosopen.org/content/down ... spberry-pi

I'm sure RISC OS Open will sort NutPi quickly if there is a problem.

[joan]

@hayder
All the GPIO libs are having to be re-written and since they are all by volunteers/enthusiasts they have to do it in their spare time

WiringPi has been done but RPi.GPIO and Joan's lib not there yet

Patience Padawan

Simon

I'd say that 're-written' doesn't accurately describe changing one number to get programatically recovered rather than hard coded!

I wish it were that easy. In pigpio's case it's two numbers.

[DirkS]

I think Dougie or somebody else posted this solution:
pip install rpi.gpio

when I did that it told me that requirement already satisfied...[/quote]
http://www.raspberrypi.org/forums/viewt ... 80#p683480

[Fidelius]

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.

Guys, keep the questions and answers flowing -- we're soaking it all in. :-)

[ktb]

I think Dougie or somebody else posted this solution:
pip install rpi.gpio

when I did that it told me that requirement already satisfied...

OK, I believe gkreidl's post was for you too:
http://www.raspberrypi.org/forums/viewt ... 47#p683847

[CJE-4D]

Anybody knows the exact size and weight of this new product?

I knew I bought that cute digital scale for a reason.

I make it 41.8g

So nearly double the A+ which comes in at 23g.

Using the same scales I get
A 31g
B 39g
B+ 41g
Pi 2 B 42g

Sorry we're sold out of A+ at present, I thought I could do the complete set.

[marked]

pi@pi2 ~ $ sudo hdparm -Tt /dev/mmcblk0p2

/dev/mmcblk0p2:
Timing cached reads: 974 MB in 2.00 seconds = 486.81 MB/sec
Timing buffered disk reads: 56 MB in 3.09 seconds = 18.11 MB/sec

on a samsung 16GB evo micro-sdcard, pi2 overclocked to raspi-config pi2 settings.

/dev/mmcblk0p2:
Timing cached reads: 668 MB in 2.00 seconds = 333.62 MB/sec
Timing buffered disk reads: 40 MB in 3.10 seconds = 12.91 MB/sec

[tvjon]

...
I updated pigpio (twice) on the 2nd. Version 27 is meant to work (I haven't got a Pi 2 so it is untested).

I've just built PIGPIO, but it crashed the Pi2 on the first test. I'll see if I can find anything to feed back.


Here's procinfo for interest:

pi@pi2 ~ $ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5

Hardware : BCM2709
Revision : a01041
Serial : 00000000badd1000

& a simplified version:

pi@pi2 ~ $ lscpu

Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1

[joan]

...
I updated pigpio (twice) on the 2nd. Version 27 is meant to work (I haven't got a Pi 2 so it is untested).

I've just built PIGPIO, but it crashed the Pi2 on the first test. I'll see if I can find anything to feed back.
...

Thanks.

C'est la vie.

If you get a chance what does the following report?

Code: Select all

#include <stdio.h>
#include <stdint.h>

static unsigned get_dt_ranges(const char *filename, unsigned offset)
{
   unsigned address = ~0;
   FILE *fp = fopen(filename, "rb");
   if (fp)
   {
      unsigned char buf[4];
      fseek(fp, offset, SEEK_SET);
      if (fread(buf, 1, sizeof buf, fp) == sizeof buf)
      address = buf[0] << 24 | buf[1] << 16 | buf[2] << 8 | buf[3] << 0;
      fclose(fp);
   }
   return address;
}

unsigned bcm_host_get_peripheral_address(void)
{
   unsigned address = get_dt_ranges("/proc/device-tree/soc/ranges", 4);
   return address == ~0 ? 0x20000000 : address;
}

unsigned bcm_host_get_peripheral_size(void)
{
   unsigned address = get_dt_ranges("/proc/device-tree/soc/ranges", 8);
   return address == ~0 ? 0x01000000 : address;
}

unsigned bcm_host_get_sdram_address(void)
{
   unsigned address = get_dt_ranges("/proc/device-tree/axi/vc_mem/reg", 8);
   return address == ~0 ? 0x40000000 : address;
}


int main(int argc, char *argv[])
{
   uint32_t a1, a2;

   a1 = bcm_host_get_peripheral_address();
   a2 = bcm_host_get_sdram_address();

   printf("paddr=%x, baddr=%X\n", a1, a2);
}

[tvjon]

paddr=3f000000, baddr=C0000000

[gregeric]

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?

[Leopold]

Is there now a gpu_mem_1024 config.txt setting? If so is the limit still 448 or can it go higher?

[jamesh]

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.

[jdb]

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.

[joan]

paddr=3f000000, baddr=C0000000

Thanks. That's what I expected.

I'm afraid that means there has been another change.

DMA is not working as it used to work.

[tvjon]

paddr=3f000000, baddr=C0000000

Thanks. That's what I expected.

I'm afraid that means there has been another change.

DMA is not working as it used to work.

& thank you for the stackexchange pointer to the github file.

I'll be working on this Pi2 today, so if you have anything you'd like to test, let me know.

[jdb]

paddr=3f000000, baddr=C0000000

Thanks. That's what I expected.

I'm afraid that means there has been another change.

DMA is not working as it used to work.

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.

[bstrobl]

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.

Can you provide us with die shots ?

[tvjon]

paddr=3f000000, baddr=C0000000

Thanks. That's what I expected.

I'm afraid that means there has been another change.

DMA is not working as it used to work.

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.

Hmm, good to know that, thank you jdb

Here's a useful thread from ARM's community forum:

http://community.arm.com/groups/process ... troduction

[pico]

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?

[Katch]

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.

[pico]

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.

OK, thanks for the clarification.

[dom]

Is there now a gpu_mem_1024 config.txt setting? If so is the limit still 448 or can it go higher?

Yes. That was added in a bootcode.bin update on Monday.
I believe it can go higher (although I've never seen a use case that would need it).

[dom]

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.

I suspect that running:

Code: Select all

sudo RPI_UPDATE_UNSUPPORTED= rpi-update

(you may need to install by following instructions for "other OS's" here).

On a Pi1, may well work, and if it works on Pi1 it will likely works on Pi2.

Obviously this is unsupported, and may break your install, so only try if you have backup up, or are planning to reinstall anyway.

[Joe Schmoe]

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:

1. The large body of existing, working, debugged (by, literally, billions of people worldwide) x86 software.
2. The large body of existing, working, debugged (by, literally, billions of people worldwide) x86 software.
3. The large body of existing, working, debugged (by, literally, billions of people worldwide) x86 software.
4. The large body of existing, working, debugged (by, literally, billions of people worldwide) x86 software.
5. A working, trusted GUI.

"Windows 10 on Pi2" has none of these.