Raspberry Pi 2 Model B

Will there be a new image for this model, or will RC12a work?

See this existing topic for discussion on the ongoing Raspberry Pi 2 Image development.

https://www.riscosopen.org/forum/forums/5/topics/3077?page=1

RC12a does not work.

However if you take RC12a and add the latest firmware (bootcode.bin etc.) from github and the latest development ROM from this site, then it does work.

Hi Chris,

Do you have a link to where we can find the files?

EDIT: OK, found them: https://github.com/raspberrypi/firmware/tree/master/boot
helps if you don’t make typos in the google search

EDIT2: I now have it working on a Rasperry Pi 2
Config/txt also needed to be changed:-
gpu_mem=64 (not 1024 as this post originally said)
framebuffer_swap=0

I think you mean gpu_mem=64 (1024 would take all the memory for GPU and must therefore be ignored!)

You are (almost) quite right. With the setting at 1024, it took (almost) all of the memory.

64 is the correct figure. I have edited my post.

Will there be a new image for this model, or will RC12a work?

The new RC14 SD card image is now on the raspberry pi site and will appear on the Raspberry Pi Foundation ‘downloads’ tab very soon. It is also available from the ROOL ‘Downloads’ tab above.

A description of what has changed is here

The new RC14 SD card image is now on the raspberry pi site and will appear on the Raspberry Pi Foundation ‘downloads’ tab very soon. It is also available from the ROOL ‘Downloads’ tab above.

RC14 is now on the Foundation download page as well. NOOBS 1.4.0 (from the Foundation site) offers ‘RISC OS’ as an option and it now does work on the model 2 as it now downloads RC14 (note: the NOOBS download is now a bit slimmer and only includes Raspian explicitly, all other OS’s on offer are actually downloaded on request from the internet).

(note: the NOOBS download is now a bit slimmer and only includes Raspian explicitly, all other OS’s on offer are actually downloaded on request from the internet).

As further described in Chris’s post here.

Does this mean that NOOBS will in future always pick up the latest RC automatically?

Have just setup my Pi2, thought I’d try to NOOBS method and go through the process as if I knew nothing about RISCOS.

NOOBS installer – brilliant, had it installed and at the desktop in 30 seconds! Very impressive.

One thing I immediately noticed is that the screen went to the highest resolution possible – which I couldn’t read so went into Configure to alter it. From a new user perspective, Configure should probably come up on 1st load or at least provide an obvious link to it in the “Welcome to RISC OS Pi” webpage that’s displayed.

In Configure, the screen defaults to “Auto” Monitor type – which is damn unhelpful as you can’t change the resolution (Why is that? Does it need EDID to list resolutions?)

The next thing that stood out is that there’s no “TV” in the Monitor type – it’s all legacy monitors, all of which don’t make the blindest bit of difference on the Pi as the GPU handles it. As a consequence of no “TV” being available, I couldn’t switch it to the 50Hz my TV wants, I was stuck with Multisync or VVGA frequencies of 56Hz and up.

Admittedly, at this point one has to go into config.txt and change it manually – this could also be detailed in the start page with perhaps a link to the config.txt Wiki.

I picked a random monitor and knocked the res down to 800×600, then took a look at the CPU configuration to see what had changed. My immediate thought was “what on earth do those two settings mean?” The wording on ARMv7 strict and ARMv7 fast don’t make a lot of sense unless you know the inner workings of legacy ARM chips.

With my techie hat on, I don’t understand how “ARMv7 fast mode” can make software run faster – that’s the implication of the wording. If I understand correctly, what it’s actually doing is just causing less Aborts to be generated from alignment exceptions (of which there shouldn’t be any anyway) – but from the wording on “ARMv7 strict mode” the Abort handler doesn’t actually fixup alignment exceptions. Based on this, what is the difference between the two? The later just turns of Alignment exceptions surely? Or is there more to it?

With regard to alignment exceptions and “ARMv7 strict mode” – is there a reason the Abort handler doesn’t fix them? Was this a technical decision, has it simply not been implemented, or has it been ruled out for some reason?

I’m curious as I bought a Pi2 specifically to implement alignment exception handling.

One other thing I noticed is that simply leaving it at the desktop gets the CPU very hot – I’m not convinced the WFI code is working as expected. It may not be putting the CPU into a low power state often enough.

Damn impressive though, well done to everyone involved in providing both the Pi2 support and the NOOBS build.

Admittedly, at this point one has to go into config.txt and change it manually – this could also be detailed in the start page with perhaps a link to the config.txt Wiki.

I stand corrected, my Pi2 has defaulted correctly to 1080p 50Hz so it’s just RISCOS that needs a “TV” monitor to match with 50Hz

I’ve also just noticed that although it’s picked up an IP address via DHCP, it’s not using the DNS servers DHCP hands out. Why do you have to go into “Host names”, tick “Try name server too” and then manually enter DNS servers? That doesn’t make sense when DHCP covers it.

It gets worse, having manually entered the DNS server and confirmed its working, it’s also not used the Gateway provided by DHCP.

Not exactly the best NOOBS experience I’d say, I’d expect something as fundamental as DHCP to work.

One final observation: When you knock the resolution down, the pinboard doesn’t move icons off screen back on. I was wondering where the Stores were, only to find they’re off the top of the screen due to RISCOS defaulting to such a high resolution.

In Configure, the screen defaults to “Auto” Monitor type – which is damn unhelpful as you can’t change the resolution (Why is that? Does it need EDID to list resolutions?)

“Auto” is just what it says if it can’t work out what MDF is in use (the Pi has an MDF held in ResourceFS in order to provide the 1080p mode that’s used on startup, and the screen setup plugin isn’t smart enough to be able to deal with that).

With my techie hat on, I don’t understand how “ARMv7 fast mode” can make software run faster – that’s the implication of the wording. If I understand correctly, what it’s actually doing is just causing less Aborts to be generated from alignment exceptions (of which there shouldn’t be any anyway) – but from the wording on “ARMv7 strict mode” the Abort handler doesn’t actually fixup alignment exceptions. Based on this, what is the difference between the two? The later just turns of Alignment exceptions surely? Or is there more to it?

It’s “fast” from the point of view that if software wants to perform unaligned loads/stores then doing it using the native ARMv6/v7 support for unaligned loads/stores is quicker than having to manually break the operation down into a series of aligned operations. It won’t make code which runs under “strict” mode any faster, but if that code was recompiled with support for unaligned accesses enabled then it would (potentially) result in a faster executable, albeit one that only works when the system is set to use the “fast” mode.

With regard to alignment exceptions and “ARMv7 strict mode” – is there a reason the Abort handler doesn’t fix them? Was this a technical decision, has it simply not been implemented, or has it been ruled out for some reason?

A little from column A, a little from column B. I did write a module that would fix up unaligned loads/stores, but found that most of the ARMv5 software I was testing with was failing without even performing any unaligned accesses, so I shelved the project.

https://www.riscosopen.org/forum/forums/3/topics/207?page=2#posts-3704

I’ve also just noticed that although it’s picked up an IP address via DHCP, it’s not using the DNS servers DHCP hands out. Why do you have to go into “Host names”, tick “Try name server too” and then manually enter DNS servers? That doesn’t make sense when DHCP covers it.

These are fair criticisms – a full explanation of why and how it is supposed to work would be useful…

Not that I think anyone should pursue this, but a significant piece of software that would benefit from unaligned loads/stores is the BASIC V module. Think of all those 5-byte string and float operations. ;-)

Ben already did that several years ago, before we realised that 99% of existing compiled code was relying on rotated load behaviour and would potentially lead to silent data corruption when running with unaligned loads enabled. All we have to do is flip a couple of compile time switches to allow the code to be used again (with the downside that things will die pretty quickly if you enable alignment exceptions, or if you try switching to rotated load mode)

result in a faster executable, albeit one that only works when the system is set to use the “fast” mode.

Bad labelling IMHO, “strict ARMv7” and “ARM5 compatability” would be understood by more people – particularly the NOOBS from the Windows world.

These are fair criticisms – a full explanation of why and how it is supposed to work would be useful…

I wasn’t being critical, just airing the experience a new non-RISCOS user would face. If the DHCP worked, it would have been a very quick and seamless experience to get connected to the net and download applications. Had I not have known to manually change the DHS/Gateway, as a new user I would have struggled.

I’m guessing that DHCP either deviates from RFC2131 – or there’s an issue somewhere as the DNS and Gateway should have been set along with the IP address.

There also doesn’t appear to be a way to view the IP settings in Configure – that could be added easily enough, I’d expect the DHCP page to show that sort of detail. From first glance the IP stack looked okay as it had picked up a DHCP address, I think the average person that’s familiar with Windows/Linux/Mac would assume that as it had an IP address you should be able to browse the Internet.

Daft question, but do the NOOBS releases go through QA? I can’t be the first person to notice this problem surely? Or am I just unlucky and hit some random issue between RO5 and my router?

I’m guessing that DHCP either deviates from RFC2131 – or there’s an issue somewhere as the DNS and Gateway should have been set along with the IP address.

My Pi(1) works with DHCP without problems. Well, there is a problem in that RISC OS boots so damn quickly, it has often timed out the DHCP attempt before the Vonets adaptor is ready. But that isn’t RISC OS’s problem. If I defer booting the Pi, it all “just works”.

There also doesn’t appear to be a way to view the IP settings in Configure

Unless things have changed for the Pi2, there is a way. Admitedly, the network configuration is a bit of a mess with stuff scattered across three or four different windows; however…

!Boot → Network → Internet → Interfaces → a button saying “Status…”.

Or just press F12 and type *Show Inet*
:-)

My Pi(1) works with DHCP without problems. Well, there is a problem in that RISC OS boots so damn quickly, it has often timed out the DHCP attempt before the Vonets adaptor is ready. But that isn’t RISC OS’s problem. If I defer booting the Pi, it all “just works”.

Like you I switch the WiFi dongle on before I power the Pi up. The Pi does seem to sit on the DHCP for a while though – a lot longer than I’d expect, so perhaps it doesn’t like the DHCP coming from my router (A stock BT Infinity job – the 1st batch they rolled out)

!Boot → Network → Internet → Interfaces → a button saying “Status…”

It should really show the DNS on that page. It’s a bit hidden, perhaps another Icon next to: Interfaces / Routing / Host names / User options … IP details ???

Interestingly, I just fired the Pi2 back up to look at this and during the boot sequence – before the desktop appeared it reported “Unable to add gateway 192.168.1.1 – file exists!” (may be paraphrasing slightly). Never seen that error before on any machine.

Okay, I’ve cleared out the manual Gateway and DNS and rebooted, incidentally – why do we need to reboot? Can the network stack not be RMReinit’d?

Following reboot, Gateway is Unset in the Status page and Primary name server is blank in Host names.

Does this mean it doesn’t like the DHCP packet coming back from my network? Is there some diagnostics I could do to help pin the issue down to help resolve it? I may as well help track the problem down as I’ve raised it as a potential issue.

I can Wireshark the DHCP traffic if it’s any use, just not sure what to do within RISCOS to provide any meaningful debug info.

On the heat issue, as I’ve discussed this with Jeffrey previously with a view to help improve it. Is there any diagnostics I can do to see how much of the time it’s in a low power state? I’m willing to muck in here and try adding WFI at various points in the system – such as a loop in RTSupport or in the SWI exit handler etc. It’s something I’m looking at adding to ADFFS anyhow, so can tinker around with putting the CPU in a low power state at various points in the system to see if it improves heat without impacting performance.

I’ve just switched back to my Pi 1 to do some testing and its setting the DNS and Gateway via DHCP automatically. It’s running the nightly build from 13-03-15, the Pi 2 is running the NOOBS build which I guess is RC14.

Oddly though, if I click on Interfaces I get the error No network interfaces were detected but the network stack is working fine.

So, at a guess there’s either a difference in the !Boot sequence that’s breaking DHCP or a build difference. When I get a chance later, I’ll try switch the Pi2 to the daily build that’s on the Pi 1 and see if it makes any difference.

EDIT: Noticed that Access was enabled on the Pi 1, so turned it off and rebooted – fatal mistake. IP now broken, so on a hunch I replaced !InetSetup with a nightly build and that resolved both the No network interfaces were detected and got DHCP working again.

Have some Pi 1 testing to do and will then try to figure out why DHCP doesn’t work on the Pi 2.

Oddly though, if I click on Interfaces I get the error No network interfaces were detected but the network stack is working fine.

If this is via a WiFi dongle then as I understand it there is no RISC OS driver for that, the dongle has to be setup externally with a proper computer (I think). The dongle is a self contained thing (I think). Not that I have got one.

It should still show the internal ethernet port.

Something changed between RC12 (IIRC) and R14. I had this too. Install the most recent !Boot (and pay special attention not to mess with the Loader file if you back up the current boot arrangement – yeah I speak from experience, oops!).

If this is via a WiFi dongle then as I understand it there is no RISC OS driver for that

I use a TP-LINK TL-WR702N

Marvellous bit of kit that presents WiFi to UTP, solves all the connectivity problems with RISCOS machines. Less than £10 2nd hand or about £15 new, I’d recommend it to all RISCOS users that want to connect via WiFi.

Be very careful! There is reason to believe that only earlier versions of the TL-WR702N work in client mode:

http://uk.tp-link.com/article/?id=395

IIRC Chris Evans has posted somewhere that they have found that only some specimens work.

Be very careful! There is reason to believe that only earlier versions of the TL-WR702N work in client mode

You need to update to the latest firmware it works perfectly. There was only one version ever released as far as I can tell – V1

Mine says v1.2 on the side and was purchased within the past year.