Raspberry Pi 2

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

Has to be to run on OMAP3 (Beagle) if you think about it.

Maybe its good that Windows comes to the Pi because maybe its time for the world to be weaned off x86?

I am under the impression that this is a special “Internet of Things” release of Windows 10. Don’t expect a desktop. In fact, given that the new SoC is ARMv7 and there’s a shedload of memory, cores, etc – I think the Windows connection helps to give the platform some creditability, at least for those who don’t know of Windows RT, but the real news probably ought to be – this spec is within Ubuntu’s sights. This could be an interesting summer…

Maybe the scared-would-be-pi-programmer can be enticed in with a bit of Windows

Will it run IE? Will it run Word? Will it run Excel? I think it’ll be either a flat NO or you’ll be stuck with an “app version”. Consider Google Docs. The browser version is quite clever and remarkably capable for something running in a browser. The dedicated app STILL cannot place a flamin’ picture on the page. Nor can you edit styles – to get rid of Tahoma that kept turning up, I had to open my doc in the browser, tweak it, then resync it to the iOS Docs app. That’s almost comically bad. I really hope that anything “Windows” doesn’t take the cut-down-app-style route.

and then convinced that RISC OS is a good alternative? (Maybe I should stop eating so much sugar?)

Er… No.
I think RISC OS appeals to those who want something light and simple and uncomplicated. People looking for an alternative to Windows will probably try Ubuntu. Does this mean Unity?

Foundation have designed together so I guess any other bugs will remain…

Damn, what a missed opportunity if so.

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.

What, like the Beagle version? ;-)

[edit: just noticed Steve already said this…]

Regarding PMT, it’d be stupid not to make the multicore support use PMT for its own threads, especially given the fact that there is a PMT multiprocessor support library for RISC OS already (although it’s written for an old piece of hardware that never took off, and AFAIK it can’t run threads on the main processor alongside CMT processes).

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?

To have an emulation for unaligned loads would be greatly appreciated, since most Iyonix software do not work with an ARMv7 processor.

Regarding PMT, it’d be stupid not to make the multicore support use PMT for its own threads, especially given the fact that there is a PMT multiprocessor support library for RISC OS already (although it’s written for an old piece of hardware that never took off, and AFAIK it can’t run threads on the main processor alongside CMT processes).

PMT does not always mean SMP (for example, Amiga OS choose AMP, since SMP was too difficult to implement). To be honest, I think AMP is better. It’s not transparent for developers (as CMT is not ‘as transparent’ as PMT), but if you adapt your application for an AMP system, you can also make it working on a cluster. Nothing to change.

IMHO, it’s more futur proof. You wan’t more power? You add cores. You wan’t more more power? You add nodes.

What, like the Beagle version? ;-)
[edit: just noticed Steve already said this…]

I was under the impression there was still some ambiguity about it due to the following statement in the ARMv7 primer:

Note that all ARMv6/ARMv7 ROM images have alignment exceptions enabled by default. This is to help track down code which relies on ARMv6/v7-incompatible unaligned LDR/STR behaviour. It is unknown when, or if, alignment exceptions will be switched back to the “off” state, so it is advised that you modify your code accordingly.

I may just have misinterpreted this statement though.

To have an emulation for unaligned loads would be greatly appreciated, since most Iyonix software do not work with an ARMv7 processor.

I seem to recall there was some talk about implementing this in the Abort handler, it would make sense considering the amount of 32bit software for the Iyonix that breaks past ARMv5.

Can confirm that last night’s nightly boots on a Pi 2; there’s an abort after finishing module init, and FileCore in use so that SDFS isn’t functional (and thus !Boot isn’t run), but otherwise things look OK. Desktop is fine, HDMI works, USB keyboard and mouse working, 1GB RAM is there, SDFS can detect my SD card, EtherUSB detects the ethernet – so all looks pretty good. USB mass storage is detected, but won’t mount due to FileCore in use.

I assume tonight when this commit is built it’ll be good to go.

Thanks Ben for your hard work :)

As far as I can see, none of the available downloads works on a Raspberry Pi model 2. I have tried NOOBS 3_12 (which warns that RISC OS might not work) and RC12a but with the latest ROM. Give up…

As far as I can see, none of the available downloads works on a Raspberry Pi model 2. I have tried NOOBS 3_12 (which warns that RISC OS might not work) and RC12a but with the latest ROM. Give up…

You need to wait for tonights alpha build.

To have an emulation for unaligned loads would be greatly appreciated, since most Iyonix software do not work with an ARMv7 processor.

I seem to recall there was some talk about implementing this in the Abort handler, it would make sense considering the amount of 32bit software for the Iyonix that breaks past ARMv5.

I tried implementing unaligned load/store fixup in an abort handler and found that it only solved half the problems I was seeing. Lots of software was failing due to other compatibility issues, ones which can’t be detected before things go horribly wrong.

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

For the lucky few who already have a Pi 2, we’ve brought forward tonight’s build and it’s there for you to grab. Note, you will also need the latest firmware from github (which also means you need framebuffer_swap=0 in config.txt). Updated disc images and NOOBS distributions will follow when things settle down a bit.

For the lucky few who already have a Pi 2

And for some RS customers,

quote
We’re really sorry…

Yesterday we launched the Raspberry Pi 2 Model B to the world. Due to the high demand for this exciting product you may experience a delay to your delivery.

We are working hard to resolve the issue and apologise for any inconvenience this may cause. You will receive an email confirming when your order is ready to be despatched. Thank you for your patience.
/quote

For the lucky few who already have a Pi 2, we’ve brought forward tonight’s build and it’s there for you to grab.

It’s dated 27-01-2015 01:25 inside the zipfile. Is that right?

And it doesn’t boot here, but I could have done something wrong elsewhere when sorting out the firmware.

I think they should of called the new Pi the Master, after all they had the A, B, B+

The compute module should be called the Electron,

solved half the problems I was seeing

Probably better than 0 :) (and better than simply ignoring alignment warnings)

There is no way to detect when the processor goes in Thumb mode? (for the other half).

Has HALDeviceComms_GPIO been updated to add in the new board type(s)?

(If I knew what I was looking for, I guess I could look in the sources, but the Pi 3 might be out by the time I understood what I was looking for/at!)

It’s dated 27-01-2015 01:25 inside the zipfile. Is that right?

This still stands as a question

And it doesn’t boot here, but I could have done something wrong elsewhere when sorting out the firmware.

This doesn’t! I’d mucked up the firmware.

In short… IT’S ALIVE!

Ooh, and how long have we had 64K colours on the RPi built-in MDF?

It’s dated 27-01-2015 01:25 inside the zipfile. Is that right?

This still stands as a question

Examine any ROM image zip file and the date stamp seen from Windows is 7 days before the zipfile creation date and rom image creation date. Reason??

Note, you will also need the latest firmware from github (which also means you need framebuffer_swap=0 in config.txt).

Many thanks. Googling Raspberry Pi GitHub seems to work. (Why is it called this – a hub for gits?)

Not sure I like the new colours, I find them a bit garish.

Has HALDeviceComms_GPIO been updated to add in the new board type(s)?

No, not yet. As you’ll see here they’ve just gone and made board identification rather more complex. It’s a shame that our GPIO device scheme didn’t just pass through the underlying revision ID but made up its own scheme, because now we have to decide how to map these new values back onto the RISC OS specific numbers. I’d also think we need to be a bit more careful about the Compute module since its GPIO assignments depend upon what it’s plugged into. And I’m not sure why there’s a “processor” field there either; technically the Pi 2 has a different processor to the Pi 1, but it’s clearly the same family of devices (the GPIO pin assignments are identical, compared to even the gender of the GPIO connectors changing between the Beagleboard and Beagleboard xM!)

Basically, I’m hoping that someone that’s more familiar with the GPIO system will make a suggestion, because the design doesn’t make much sense to me…

Not sure I like the new colours, I find them a bit garish.

You mean the colours on the Pi? If you read what I said above, you need framebuffer_swap=0 in config.txt (the red and blue colour components are now the wrong way round for us by default).

Ah, that makes sense – I was wondering what was up with the colours. For those who don’t have one yet, some screenshots (click for larger) before the framebuffer_swap:

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.

Not sure – I think I saw the mini-rainbow-square once but was never able to reproduce it again…

On the subject of GPIO, there seems to be precious little actual hardware manipulation in s.GPIO in the HAL. It doesn’t even seem to be passing the address of the registers out to the GPIO module, and because those have changed I think you’ll need to wait for Tank to make the necessary alterations before playing with GPIO on the Pi 2. (Hint – this is why the HAL was designed the way it was – the lowest-level hardware accesses should really have been there, then they’d have inherited the address changes the same as all the other peripherals did…)