Raspberry Pi 2

Ben, any ideas what’s up with the coloured blob in the top right? Is that coming out of the GPU side? The mouse pointer goes underneath it.

I wondered what that was too, but I’d convinced myself if was the monitor, not the Pi. Also, it seems like changing the resolution/monitor settings in configure has no effect, and Boot.Choices.PreDesk.Configure.Monitors is ignored. I seem to remember this has been an issue for at least the last month (although I didn’t worry a month ago, because I’m running that one headless with VNC).

I should also warn that changing into a 16-million-colour screen mode from one with a lower colour depth doesn’t seem to work at the moment. Not sure why – has anyone experienced that with other recent nightly builds or is this a new bug?

The Mini-rainbow-square is the GPU reporting under voltage.

The Pi forums are currently suspended but I found the details here:
https://web.archive.org/web/20141221150119/http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=82373

I should also warn that changing into a 16-million-colour screen mode from one with a lower colour depth doesn’t seem to work at the moment. Not sure why – has anyone experienced that with other recent nightly builds or is this a new bug?

Appears to be fine for me with a ROM from the 30th of Jan (and firmware which is several months old). I’ll be updating ROM+firmware shortly, so if there are any issues I’ll hopefully be able to spot which is at fault.

One thing you could try though is increasing the amount of RAM allocated to the GPU – in the past 32MB was fine but 16MB would cause issues.

The Mini-rainbow-square is the GPU reporting under voltage

Ah – interesting. Yes, the guys at Pi towers did warn me that the Pi 2 needs a beefier PSU than the Pi 1. Sounds like we’ll be getting lots more reports of this type!

For the record, the PSU I’m using which is working OK is rated as 2A.

One thing you could try though is increasing the amount of RAM allocated to the GPU – in the past 32MB was fine but 16MB would cause issues.

Ah again. Looks like the minimum GPU allocation has gone up to 64MB then. Thanks for the pointer.

(Just to spell that out for the other experimenters, that means gpu_mem=64 in config.txt)

The Mini-rainbow-square is the GPU reporting under voltage.

Hmm, I didn’t notice it under Linux, but maybe the config disabled it. My power LED was indeed off. I was powering my Pi from my desktop PC with a new known-good USB cable that worked on the Pi 1 – useful to know that it can give some more helpful diagnostics (though writing ‘power low’ would have been even better :)

(As an aside, I’ve had huge problems with USB cables which turn out not to have enough copper inside to power things properly – finally came across these that charge my phone faster than anything else I have. ‘20awg’ is the magic word)

Todays build works fine for me on the Pi2, SDFS is working too. I downloaded the ROM at 21:00, has there been a second build today?

There was a second build at 17:13 after the usual nightly with a FileCore bug in it. If it works, you have the latest.

Ah! That explains it. Thanks Theo!
(Seems I missed this when I read this thread! Doh!)

I was powering my Pi from my desktop PC

Me too. That explains that, then!

Deleted as I realised I’d misunderstood the posting I was replying to.

I’m truely amazed you got RISC OS up and running on a board that’s only been out for a few hours!
\o/

I should also warn that changing into a 16-million-colour screen mode from one with a lower colour depth doesn’t seem to work at the moment. Not sure why – has anyone experienced that with other recent nightly builds or is this a new bug?

ROM 31Jan15 also shows this, and changing down from 16M to 64K colours is also hazardous. This is on a Raspberry Pi B at 1680×1050 running the latest firmware. gpu_men is already 64.

1680×1050 at 64K is definitely broken. Still haven’t been able to reproduce any issues when changing into a 16M colour mode though. What modes are you changing to & from?

It’s a shame the “get pixel order” and “set pixel order” mailbox messages don’t seem to do anything useful. As it is I don’t think we’ve got any way of detecting the framebuffer_swap setting from the config file or any way to set it to the value we want (other than changing the config file!)

OK, I’ve been able to recreate the issues with 16M colour modes now. It looks like these are both issues with the latest firmware – changing through the modes in different orders will influence whether things do or don’t work, and my older firmware (June last year) doesn’t appear to have either of the issues (with gpu_mem set to 64 for both).

1680×1050 at 64K is definitely broken. Still haven’t been able to reproduce any issues when changing into a 16M colour mode though. What modes are you changing to & from?

Starting in 1680 × 1050 16M, selecting 256 colours drops the resolution to 1600 × 1200. Moving up to 64K colours at that resolution can crash but it it successfully starts the mode then a further move up to 16M colours at 1600 × 1200 may crash. It is not entirely consistent. As far as I can see moving up to 16M colours at 1680 × 1050 is OK.

All seems good at 1920 × 1080 which the monitor will accept even though its native resolution is 1680 X 1050.

It looks like these are both issues with the latest firmware

The problem is present with firmware downloaded 16Jan15 which is the point at which framebuffer_swap=0 was required. Firmware from April last year is OK.

(N.B. This is from an old Raspberry Pi Model B, not 2, not +. Not that that should make any difference…)

I’m getting a hang during booting about half the time. It hangs after DHCP has completed and during/after the splash screen redraws with the Raspberry Pi trademark text at the bottom. The pointer freezes (Not hour glass) and the Iconbar doesn’t appear. I’m using last nights RISC OS build and start.elf 19:54:14 31.1.2015.

The power LED is on and there is no rainbow square so I don’t think it is the PSU.

It is pretty stable and nippy if it completes booting.

If you read what I said above, you need framebuffer_swap=0 in config.txt

I did read it but got the spelling of ‘framebuffer’ wrong! Now OK, thanks.

I’m getting a hang during booting about half the time.

Me too, although if it completes the boot it seems stable.

A bit more information, I’ve now seen it a couple of times hang half way through redrawing the final splash i.e. no black window with ‘Contacting DHCP…’ etc. The bottom quarter or half of the splash being displayed.

Also twice it actually got as far as displaying the Iconbar and then hang.
And also two hangs with a completely black screen, not sure if it had done the initmod as I wasn’t watching it boot.

n.b. Our RTC and temperature sensor module is working correctly and we have suitable moulded and acrylic cases in stock!

Assuming that the OS related issues are sorted at some point in the future does anyone know if I’ll still be able to use my NutPi programs with the new Pi?

I have only tried the DDE off the NutPi so far and it doesn’t work. It complains that the software will only work on a Raspberry Pi so I guess there are some hardware checks that fails on the Pi 2.

Jon: ROOL are aware of this and working on an update. Other programs on NutPi may also fail.
On a very quick test !Photodesk which is part of NutPi is working correctly.

Thanks, look forward to the update.