Setting up a Pi3

Hi,

Having finally changed to an HDMI-capable display, I have just tried to set up a Pi3 from scratch this evening with no success.

I started with the Pi RC14 disc image copied onto a micro SD. I then copied over the nightly beta ROM and the HardDisc image using the Rev. 1 Pi.

The bit I’m stuck on is that the hourglass seems to be coming on continuously. I presume this is due to something in the standard disc build !Boot but does anyone know what?

The firmware also needs updating.

You will also need a kludged ZeroPain module. Many applications will need to be recompiled before they will run on a Pi 3 (UnTarBZ2, LanMan98, etc. etc.) but RISC OS itself should run OK.

Sorry – should have said: I updated the firmware. The machine is sat in the RISC OS desktop with the hourglass on. So the firmware has obviously been OK and the latest ROM image (yesterday) looks to be OK.

Is there something incompatible in the current HardDisc image likely to cause RISC OS to lock up at the desktop phase of booting?

I haven’t checked ZeroPain yet – I had assumed the hard disc image was now ZeroPain safe – is that a false assumption?

Try alt-break. I had a similar problem myself, setting up a Pi 3 using a fresh RC14 image as the base. I think there might be a UnixLib app in there which only runs on first boot and is getting stuck in an abort loop trying to use SWP. IIRC subsequent boots worked fine without me needing to change anything.

I think there might be a UnixLib app in there which only runs on first boot

As I recall there is an HTML intro page baked into the startup which attempts to run NetSurf, which fails. I don’t have an RC14 to hand to be more specific.

Ah – yeah…Alt-Break…Erm…

So my Pi uses a Mac keyboard that I have plugged into it (which doesn’t have a ‘break’ key). I have made a key mapping for the UK Mac keyboard. But of course I can’t softload the Keyboard module onto the Pi because it hasn’t finished booting :-(.

I think David’s right – there is a first time HTML file that is the likely culprit.

I’ll have a rummage and see if I can find it.

Has NetSurf been fixed? If so, is there any chance the nightly hard disc image could be updated with the newer NetSurf?

Has NetSurf been fixed?

I know some fixes have made it into UnixLib, but I believe there’s still some instability issues to sort out.

http://www.riscos.info/pipermail/gcc/2016-March/006611.html

Not sure whether the nightly builds of NetSurf use latest GCC or stick to a release version. Chances are someone needs to manually specify which GCC revision to use.

If so, is there any chance the nightly hard disc image could be updated with the newer NetSurf?

NetSurf isn’t in the base hard disc image, only on the Pi RC image.

If you have a micro SD to SD adapter you should just be able to just pop the card into the Pi 1 in order to let it complete the first boot.

Ah – yeah…Alt-Break…Erm…

Try your luck with ‘Escape’ just after the ROM initialise messages run to get to an unbooted desktop.

there is a first time HTML file that is the likely culprit

As I recall that is a ‘Run at Boot’ item and can be nobbled manually from Choices.Boot.Desktop.

OR sort out the card issues in the other more obliging Rev 1 Pi.

Has NetSurf been fixed?

The UnixLib issue has not been fixed, so no. (NetSurf is not in the nightly beta harddisc image.)

As NetSurf doesn’t work on the RPi3, direct downloads are not possible. I just use VRPC and ShareFS for that, works a treat.

HTH.

Not sure whether the nightly builds of NetSurf use latest GCC or stick to a release version. Chances are someone needs to manually specify which GCC revision to use.

The latest nightly still fails on Pi 3 :(

The latest nightly still fails on Pi 3 :(

The current fix that has been made to UnixLib does enable NetSurf to run. It’s only a partial fix for UnixLib as other programs still have problems if they use Pthreads. e.g. Otter browser and MPlayer.
Until the fix is complete and added to the NetSurf build system even the latest builds of NetSurf will cause a lock up on the RPi 3.

Nearly all the programs available in PackMan on the Rpi 3 will fail to run. Also PackMan itself which would need the SD card image updating as well.

The NetSurf developers invite all RPi 3 owners to try NetSurf CI build #3460 or later. It is hoped that they will run satisfactorily on the RPi 3.

Hi Dave. I’m slightly confused. I thought NetSurf’s problem was in UnixLib.
Chris G wrote: “The current fix that has been made to UnixLib does enable NetSurf to run.”
Do users need both the “NetSurf CI build #3460 or later” from here
AND the latest UnixLib 1.03-2 from here
unfortunately there is no date given on that page, so I’m not sure if this is a recently updated version.

I’m slightly confused. I thought NetSurf’s problem was in UnixLib.

It was. UnixLib is a library that NetSurf (and most software built with GCCSDK) are statically linked against. We have backported the UnixLib fix to our toolchain. As such any recent builds of NetSurf (#3460 onwards) include the fix.

Your other link is to SharedUnixLibrary, which is a different thing.

Do users need both the “NetSurf CI build #3460 or later” from here AND the latest UnixLib 1.03-2 from here

Only NetSurf #3460 is required. The current SharedUnixLibrary 1.14 suffices.

Thanks Michael for the explanation i hadn’t realised it was statically linked.