NetSurf undefined instruction

With any Netsurf 3.11 after CI #5300 I get an Undefined Instruction error at &004D1C88 error. With SparkFS 1.46, on RO 5.27 on Rpi3B+.

Running NetSurf #5308 fine here on ARMX6, RO 5.29 (3-Nov-2020). What are you doing when you get the error?

The ARMx6 does tend to be more forgiving than a ARMv7 Pi, but saying that the Pi4 which is even fussier, seems to be ok with #5308 too.

To find the instruction associated with the crash you’ll need to decompress the !RunImage, which ARMalyser isn’t happy doing on its own for some reason, but xpand from a Task Window works. You’ll need to tell us the exact version for the error location.

Undefined Instruction error at &004D1C88 error

What URL are you going to? What instruction is there at that address? What CPU mode do you have configured? Is that address even inside the NetSurf Absolute?

decompress the !RunImage, which ARMalyser isn’t happy doing on its own for some reason

That’s one of the bugs I wanted to fix in ARMalyser…if you would kindly consider releasing the source code.

I have considered it, but have no time to do it. But in the mean time, please let me know if you find problems like that, as if I don’t know about it, I can’t fix it.

I have considered it, but have no time to do it.

Had you considered a small agreement with Jon? Not Open Source but a little more Shared.

What URL are you going to?

None. I had only just clicked on !NetSurf. But I am now using RO5.27 on an ARMBook and using NetSurf 3,11 #5310 right now. So I am almost certain that it was nothing to do with NetSurf but with the SD-card in my Rpi3B+. I also raised a thread Micro-SD card readers in this forum. I was happily writing a program, using StrongED, when to my surprise I found that the code I was looking at was not what I had most recently saved, but what I had written an hour or so earlier. I jumped to the conclusion that there had been some sort of memory fault. I had also found that the Configure keyboard was giving an error Invalid Component ID (0×14) . At that point I decided to upgrade to RO5.28 using the ROOL in situ tool. Loading the software worked fine, but after I loaded in the new ROM and rebooted I only got a black screen. So I think the SD-card was bad. And then I discovered that my card-reader was bad. The trouble with glitches is that they tend to come in crowds and you do not know which caused what.

Sorry for all the noise, and thanks for the good advice.

I would recommend a small SSD with a USB3 to SATA cable, far more reliable than an SD card. The only Pi’s I use SD cards for main storage on are Pi Zeros. All systems are backup up every night to external storage, but if corruption creeps in, rather than the card failing suddenly and outright, I’d be in the same position as you and have to restore for a known good image.

The problem here is that Rpi1, Rpi2 and Rpi3 do not have USB3, only USB2, I think. I run my Raspbian Rpi4 the way you suggest. In fact it boots off the SSD, that possibility only coming in with a firmware change for the Rpi4 this year (not sure if this is reflected in the ROOL advice about installation of RISC OS). I also have Manjaro in a Lyntex hard-drive, which I can plug in instead of Raspbian.

At the moment I am using RISC OS on the ArmBook, with a powered USB hub attached with a hard-drive plugged in. Getting RISC OS back on the Rpi3 will have to wait. Maybe when Rpi4s have replaced the Rpi1/2/3s the use of micro-SD cards will be unnecessary.

It doesn’t matter if the older Pi’s have only USB2, the USB3 adaptors still work, but obviously slower than using if using USB3. The reason I mentioned USB3 specifically is that most USB2 adaptors are old slower SATA II ones, where as the USB3 adaptors are SATA III, which are faster than SATA II even when using USB2. Plus when you do upgrade to a Pi4, you can carry on using the same adaptor.