Pi 3 bugs

No, it’s also a mistake. After dismount/remount, there is no error detected any more.

Is it only that particular type of device that exhibits this behaviour?
I’m afraid if one of my devices behaved like that, I’d consider it “incompatible”. Any error message at all (real or imaginary) ought to set alarm bells ringing.

Not sure. A SSD is like a whole computer.

So’s an SD card. We don’t need to wait for them to start up. ;-)

High denity Flash memory is quite error prone, so managed storage (SD cards, SSDs, USB keys…) provide an illusion of good reliable media with error correction and bad block management. As capacities increase, the reliability drops (atomic scale entropy), so the sophistication of the management increases.
As ssuch, the device will contain two distinct parts (may be combined, or two ICs): the big Flash array, and the controller. Do not be surprised if your 8GB SD card is a 64GB Flash array riddled with bad blocks. The controller is often a very customised 8051 or ARM devices (Samsung SD cards used to use a customised ARM7TDMI, but I suspect it’s probably a Cortex-M nowadays), both capable of running in the order of 100MHz or more. As such, it is usually cheaper to add a controller and get it to examine and note the available good capacity by itself than to actually properly test the Flash array.
[maybe you’re starting to see why SD cards can exhibit ‘issues’ with devices such as the Pi; all are very much not equal]

One thing of note is that because of the huge variety of different types of Flash device, it isn’t feasible to create a fixed “ROM image” for the controller. There is actually an undocumented process to update the on-board firmware, as it itself is held in separate Flash in the microcontroller (and is useful for, say, fixing the reported device size). This is how dodgy outfits can fake cards with larger capacities than they really have – they just modify the firmware to report a large size.

I wonder how long until somebody comes up with a hack to tweak the firmware of SSD drives? As all data passes through the controller, it isn’t out of the realms of possibility for it to understand rudimentary extfs to, for instance, recognise the passwd file is being asked for, and if conditions are right, to instead present a different one stored in an unused bit of the Flash array. Okay, it’s a bit tricky to imagine this, but there’s a real possibility to have a back door baked right into the controller itself.

Is it only that particular type of device that exhibits this behaviour?

It’s constant on my USB SSD, intermittent on my USB HDD. Anyway, data is OK on both.

Okay, it’s a bit tricky to imagine this, but there’s a real possibility to have a back door baked right into the controller itself.

Haven’t Lenovo been accused of doing just that recently?

Also, never mind back doors it sounds like a great place to hide something like stuxnet

Utilising the development ROM (6-March-17) and associated files, I have observed a new issue that seems at the moment only to relate to !Writer 1.10 (Nut Pi Edition). It also occurs when dragging and dropping a URL from !NetSurf to !Writer.

!Writer crashes with the following error message "Internal error, no stack trap handler: Internal error: abort on data transfer @FC1DD5C8, PC=0008F394: registers at 000CF430. This happens when copying from the global clipboard, when dragging and dropping a URL from !NetSurf or a file from a window to !Writer.

A ZeroPain log file is created.
Time: Mon Mar 6 22:02:06 2017
Location: Application space
Current Wimp task: Writer+
Last app to start: Filer_Action …

I thought there were unresolved issues with Writer.

I had no idea where to put this but I found two programs that don’t work correctly on the Pi 3

UnTarBZ2. It seems to hang immediately after the creation of the intermediate tar file as it creates a zero byte tar.

!Nettle. ssh worked fine on the Pi Zero and B but not on the 3. It allows for the creation of a session, and entry of a username and password but hangs directly after.
Even with a fresh build of !Nettle with a fresh build of GCCSDK it still happens.

As a quick test – load the !RunImage file into !Zap and search for ‘SWP’ instruction?

UnTarBZ2 doesn’t seem to. It just seems to be a conglomeration of GNU utilities. Trouble is autobuilder can’t currently build tar.

!Nettle seems to have some SWP instructions kicking around.
I’ve never looked at the source. Does it have asm? I’m using the post Pi3 fixed GCCSDK to build it.
In UntarBZ2’s case it’s probably just old files with incompatibilities.

I’ve had this same MicroSD in the Zero, 3 and B. I can confirm Nettle and UntarBZ2 work properly on the B and Zero but not the 3.

Same issue with UnTarBZ2 here. It’s one of the only things keeping me on a Pi 1 (the other known-bad one was PDF, but I saw an update come through PackMan the other day and haven’t retested it yet).

PatchSWP will patch Nettle.

Patch to allow !Nettle to work with RPI3/Armv8

Replaces SWP instructions for LDREX/STREX pairs

Application:!Nettle &2000
Description:Nettle
Patch:allows !Nettle to work with RPI3/ARMv8
File:RunImage &FF8
Location:&153560
ChangeWord:&6C697542 &6C697542
ChangeWord:&65732064 &726F4674
ChangeWord:&6E697474 &72413D3E
ChangeWord:&75207367 &33766D
ChangeWord:&20646573 &E1901F9F
ChangeWord:&63206F74 &E2811001
ChangeWord:&74616572 &E1802F91
ChangeWord:&68742065 &E3320001
ChangeWord:&70207369 &AFFFFFA
ChangeWord:&72676F72 &E3A02001
ChangeWord:&72206D61 &E1A0F00E
ChangeWord:&69757165 &E92D1000
ChangeWord:&61206572 &E1902F9F
ChangeWord:&656C2074 &E180CF91
ChangeWord:&20747361 &E33C0001
ChangeWord:&41206E61 &AFFFFFB
ChangeWord:&41204D52 &E8BD1000
ChangeWord:&69686372 &EAFFAE97
ChangeWord:&74636574 &E92D5000
ChangeWord:&20657275 &E1921F9F
ChangeWord:&50432033 &E3A0C001
ChangeWord:&74612055 &E182EF9C
ChangeWord:&6E757220 &E33E0001
ChangeWord:&656D6974 &AFFFFFA
ChangeWord:&2E &E8BD9000
Location:&13EF90
ChangeWord:&E1001092 &EA005176
Location:&13F004
ChangeWord:&E1002091 &EA005160
Location:&153988
ChangeWord:&E1021091 &EBFFFF06

UnTarBZ2. It seems to hang immediately after the creation of the intermediate tar file as it creates a zero byte tar.

bunzip2 is the SWP containing component, !PatchSWP does it.

bunzip2 is the SWP containing component

What about the latest version on riscos.info? can that be updated instead

What about the latest version on riscos.info?

That version is not RPi3 compatible. There may be an RPi3 compatible version on Jenkins, http://ci.riscos.info but Jenkins is down.

I found a later build of bunzip2 on my autobuilder, I am not entirely sure how that happened, I think it got built as part of something else, I don’t immediately see how to build it explicitly. This build is RPi3 compatible and has just fully unpacked a ROM on the RPi3.

I’ve rebuilt and uploaded the latest bzip2 package to the riscos.info site. It should appear on the site and in PackMan tomorrow. The new version is 1.0.6-5.

If there is anything else on the riscos.info autobuilder site that people require for their Raspberry Pi 3 that doesn’t already work, I am currently setup so I can try a rebuild and upload it if the build is successful. I don’t have a Raspberry Pi 3 to test, so please try things as they are uploaded.

I’m relatively new to RISC OS, by which I mean I started experimenting with it last Friday after getting it to run on a Raspberry Pi 3. This is a somewhat disjointed account of my adventures trying to get things to run.

I’ll be happy to break these out as needed, and the Pi 3 seems to be running it well enough that I can help perform experiments if needed.

I built the SD card from RC14 with the latest Pi firmware from Github and the nightly ROM build from the main site. My monitor didn’t really like RISCOS, but lying about its model let me set a 1280×960×75 mode thta worked acceptably well. I’ve heard rumors of EDID support but haven’t figured out how to enable it nor if I have it. This also let MODE 32 work in BASIC, where previously it would complain that it was getting a signal it couldn’t use. I have no idea what caused that difference – perhaps I don’t understand what a “Generic” monitor is compared to similar-enough other models.

Speaking of BASIC and thus software development, I also totally managed to use the stock ARM cross-assembler and binutils to produce Absolute programs, albeit not any that did much. But the principle is sound, which is always fun.

As for installing other things: PackMan would hang the entire system on launch, such that the only thing I could do was hit Alt-Break and kill the application. PlingStore was not much better. Fortunately, I could download those from elsewhere and drop them into place. This made PackMan work flawlessly but the PlingStore would still crash with a fatal error whenever I tried to contact the servers. Not sure what’s going on there. ZeroPain didn’t list anything.

I also wound up manually upgrading NetSurf, and that was fine too. Meanwhile, Nettle worked out of the box after installation. With those two apps installed I was as network-capable as I really needed to be.

Most of the other things I tried to install via PackMan didn’t work. AlienBlaster and Mednafen both hung the same way PackMan did pre-patch; xu4 said I needed a better UnixLib; Curl wanted
CACertificates and couldn’t determine that “CaCertificates” was that thing. It worked anyway, but from that point onward trying to do anything with PackMan slipped in a command to uninstall Curl.

GCC mostly worked, though the native GCC port is awfully alien to someone used to POSIX systems. asasm’s syntax also seems to bear little relationship to that of arm-linux-gnu-as. StrongEd runs fine as far as I can tell, but I’m not comfortable with using it yet.

ADFFS produced a ton of complaints in ZeroPain, but it did work, and Zool ran flawlessly on Pi3 and emulation. That was fun to watch go. Hopper, on the other hand, wanted a 320×256 graphics mode that my monitor was unwilling to provide. Meteors, MineHunt, and the other stock Diversions all seemed to work fine, though.

I have not particularly played around with the GCC SDK cross tools, though as noted I did do a bit of experimentation with the arm-linux-gnu cross tools and custom linker scripts. Those did perform admirably for basic stuff, but most of the programs I have here that would be worth trying to port will require more work than a few lines of assembly! I’m very interested in being able to port SDL 1.2-based programs to RISC OS – however, I’m not clear on what’s needed to make this happen just yet.

Poking around these forums has suggested that I won’t get much further on the RPi3 without a working UnixLib. The purported downloads looked a lot more heavyweight than what it seems like I’d need for xu4 or whatever.

Be careful where you get software from – until recently UnixLib used the SWP instruction, which meant everything feel over on the Pi3.
A lot has been fixed, but obviously older versions of software will still show the problem.

ADFFS produced a ton of complaints in ZeroPain, but it did work, and Zool ran flawlessly on Pi3 and emulation. That was fun to watch go. Hopper, on the other hand, wanted a 320×256 graphics mode that my monitor was unwilling to provide. Meteors, MineHunt, and the other stock Diversions all seemed to work fine, though.

Some untested advice: Adding ‘disable_mode_changes’ to CMDLINE/TXT in the Loader partition and loading the AnyMode module (http://www.pi-star.co.uk/anymode/) should stop all mode-related worries at the expense of a little bit of speed. (Untested as my Pi hasn’t been updated for a while now)

ADFFS produced a ton of complaints in ZeroPain

Are you running the latest release of ADFFS, currently 2.60? Page Zero accesses by ADFFS were switched to legal OS calls, once Jeffrey added some OS extensions for Adrian and myself. As for games themselves, I’ve fixed most Page Zero accesses by correcting the bugs in the code, in the game boot scripts.

Some untested advice: Adding ‘disable_mode_changes’ to CMDLINE/TXT in the Loader partition and loading the AnyMode Module should stop all mode-related worries at the expense of a little bit of speed.

They won’t affect speed, but are both required for the Pi to support legacy resolutions and overscan modes. The only side-effect is the Pi will be running at the resolution fixed in CONFIG/TXT and will up/downscale appropriately.

asasm’s syntax also seems to bear little relationship to that of arm-linux-gnu-as.

GNU as? Proper ARM code is supposed to look sort of like the RISC OS source – a lot of it was written by the people who designed the ARM, so…

;-)

They won’t affect speed, but are both required for the Pi to support legacy resolutions and overscan modes. The only side-effect is the Pi will be running at the resolution fixed in CONFIG/TXT and will up/downscale appropriately.

Right, mental hick-up here. After decades of Archimedes/RISC PC usage I still associate larger resolutions with speed impact. :)

I still associate larger resolutions with speed impact. :)

Happened on PCs as well if you had one that shared system memory with the graphics…

Happened on PCs as well if you had one that shared system memory with the graphics…

Now guess who has a poor little Notebook with Intel HD3000 graphics. :)

:-) EeePC901. Dunno what the Intel graphics chipset is, but it sucks. Can barely do 720P H.264 and 1080P is a joke. Stuff the original Pi finds effortless.

I still associate larger resolutions with speed impact. :)

Which for DTP, bit image graphics, vector graphics, text, code, most web surfing etc. etc. is a matter of no consequence. My early Pi manages 24 Hz at 3840×2160, which is absolutely fine for everything I do. The Mac only manages 30Hz – enough for video editing.

Poking around these forums has suggested that I won’t get much further on the RPi3 without a working UnixLib.

Just patch incompatible software with PatchSWP. And enjoy.
Almost everything I tried works here.