Raspberry Pi 4

Chris, if you mean the boot eeprom firmware, I just updated that today, using PiOS. Files in the boot partition may not be up to date.

Is it the drive that’s dead, or the drive interface in the Iyo? If you have one handy, a USB to IDE interface should let you plug the drive in to the PI. You might be able to recover some things that way.

if you mean the boot eeprom firmware, I just updated that today, using PiOS. Files in the boot partition may not be up to date.

There are different update channels for the eeprom firmware. By default it’s set to critical which dates from 16th April. The stable channel has the required USB boot support.

You can check the boot loader version in RISC OS with,

*vcgencmd bootloader_version

The start4/elf and fixup4/elf in !Boot.Loader may need to be updated from here.

Will, yes, the drive is really dead – it doesn’t even go through its power-on initialisation.

I’ve lived for 13+years without serious use of the Iyo – the most critical thing is the source for the lpr driver. The driver is written entirely in ARM assembler, and I believe (hope) that I can remember enough about the techniques I used (including screwing with the system stack pointer!) to reconstruct a reasonable set of sources from a disassembly.
Andrew has been in fear of every new hardware architecture and OS version breaking my code, but it apparently continues to run without problem! The driver is fully multi-threading (re-entrant), multi-tasking.

Chris, I’ve been using the stable branch of the eeprom. vcgencmd reports Aug 31 2020.

*vcgencmd bootloader_version
Aug 31 2020 10:07:44
version 5c41dcec664690fa692969e860623543a868c55d (release)
timestamp 1598864864

Yes, I’m posting from NetSurf/RO now. :)

Chris Gransden, have you tried running Sunfish on the Pi4?
I downloaded Sunfish and your modified !RunImage. It all seems to work well except on dismounting a share – it gives an “abort on data transfer at &0005E338” and the front end quits. The backend module appears to continue running with no problem. When the front end is restarted, the mounts are all restored to the icon bar, except the one you dismount so the abort must occur after the dismount is actioned.

Chris, I suspect that the reason I’m not seeing the eeprom splash screen is that my display (a Waveshare 15" HDMI touch screen) isn’t capable of displaying the low resolution mode.

That raises another question – PiOS supports the USB-interfaced touch screen functionality of the Waveshare screen, is there any touchscreen support for RO?

is there any touchscreen support for RO?

Any? Yes.
Some that supports your screen? Try it and see :)

Touchscreen support for RISC OS is OK for absolute coordinate systems (like the Adafruit 5" screen) but it treats it as a mouse with a single button. Having two finger touching will not work so all the new stuff like spreading your fingers to zoom in etc. will not be understood.

Merge requests for XHCIDriver and HAL_BCM2835 have now appeared.

… but not yet made it to the daily rom, which is still 27 Aug. I presume this is being worked on?

Is any specific configuration needed to enable touchscreen support? If I boot a PiOS stick, the touch works but swap to a RO stick and there’s no response to touches.

Here’s an example splash screen with no boot drives attached.

The bootloader needs updating (Aug 16th is the critical one, I think). Oops, no it doesn’t April 16th 2020 or later is fine.

Is any specific configuration needed to enable touchscreen support?

No, it is built in to RISC OS but does require a USB-connected device which uses absolute coordinates. The device then appears to behave exactly like a mouse.

My Pi4 boots from an SSD drive but needs some manual intervention to get there. At the first stop, I need to do a !Boot which takes me to the desktop and then use rmkill fat32fs to complete the process. Is there an extra step that I can take to make this a fully automatic process?

can take to make this a fully automatic process?

Assuming you are booting without an SD card. As a one off you can do,

*configure filesystem scsi

Double click !Boot. Click menu then CMOS→Save.

Copy the the !Boot.Choices.CMOS file to !Boot.Loader.

Reboot.

No, it is built in to RISC OS but does require a USB-connected device which uses absolute coordinates. The device then appears to behave exactly like a mouse.

So, I guess that the touch function of my screen isn’t compatible. I’ve asked the question of Waveshare, but I’m not sure whether they have any experience with RO.

Assuming you are booting without an SD card. As a one off you can do,

Yes and finally I have two Pi4s booting from m.2 msata samsung evo ssd drives. After a week of trying to sort it out, it seems an anti climax to have it all working flawlessly.

Double click !Boot. Click menu then CMOS→Save. Copy the the !Boot.Choices.CMOS file to !Boot.Loader.

This did not work for me and in the end, I reformated the drives, repeated the process and voila all worked. Many thanks for all the esuggestions and previous posts. I know more about RISC OS boot process than I did a week ago.

USB 3 fat32 pen drives in the USB 3 sockets are not seen but work in the USB 2 sockets. A USB 2 hub in the upper USB 3 socket works OK but some items plugged into it are not seen, if the hub is plugged into the lower USB 3 socket. Otherwise it all seems to work correctly.

Using a test rom (29-Aug) with:
PCI 0.19
WindowManager 5.77
Shared C Library 6.07
USB Driver 1.31
DWC Driver 0.37
XHCI Driver 0.29
SCSIFS 1.35
!Paint 2.36
ToolBox 1.59

and with the following regressed from RC16 to:

SCSISoftUSB 0.27
DrawFile 1.59
WindowScroll 0.01
LanManFS 2.62
EtherUSB 0.41
!Draw 1.40
!Alarm 2.94
!Chars 2.04

means that USB 3 drives in USB 3 sockets are not recognised.

With a test rom (5-Sep) with:

Shared C Library 6.08
SCSIFS 1.36
!Edit 1.75

then USB 3 drives can be plug and play in USB 3 sockets. A USB 2 hub however still has some problems, in certain sockets, certain drives are not seen. Re-plugging a USB 2 pen drive brings up an AODT error.

So, I guess that the touch function of my screen isn’t compatible. I’ve asked the question of Waveshare, but I’m not sure whether they have any experience with RO.

Probably not but they might have some info that would help someone make a driver.

Seeing the XHCIDriver merge mentioned on the Events page I was hoping that the USB ports would be working in this morning’s build, but it was not to be.

On firing up this morning’s build on a 4GB Pi 4, the Ethernet port works but the USB ports are “as a dodo”.

I wonder what is amiss?

Seeing the XHCIDriver merge mentioned on the Events page I was hoping that the USB ports would be working in this morning’s build, but it was not to be.

…

I wonder what is amiss?

This update only contains some initial data, the main event is still pending.

p.s. The better news is that there has been some movement on the USB3 ports not seeing USB3 devices issue. A local build here can now see the Samsung USB3 T3 SSD containing Raspberry Pi OS. Slightly confusingly on first boot the RPi4 failed to find its boot SCSI SSD. This was because it is now SCSIFSDrive 5.

Excellent progress.

I wonder what is amiss?

Patience young padawan. Only when the dark side (the HAL) and the light (XHCIDriver) come together will greatness be achieved.

In the meantime there’s a test ROM which Chris Hall has kindly tested available with both changes in, though as it’s just off my development Titanium it may have other random half updated things in it.

it may have other random half updated things in it.

I can confrim it does, see above.

The test rom (5-Sep-2020) seems to work well on the Pi4 under RC16 [with the exception that a hub unplugged and plugged in again will prompt an AODT at XHCI+004160 for a JTAG breakpoint that has not yet been removed but then recover], USB 3 devices work and run at USB 2 speed. USB 2 devices mostly work but the XHCI driver (also used on the Titanium) has some sensitivites to bus powered USB hubs which can suffer from voltage drops as the inrush of current takes place, especially on the Pi. Devices can fall off the bus in software terms and thus not be seen (they do not injure themselves doing this).

With XHCI most of the protocol negotiation is done by the hardware so:
a) it’s faster than EHCI or OHCI;
b) the software can’t stick delays in to work around quirky devices;
c) the device must follow the USB spec to the letter.

(Thanks to Sprow for this info.)

The HAL bit was merged 14 hours ago, the XHCI driver bit was only updated to include USB2/USB3 negotiation 13 hours ago (on the git server) and is thus still ‘open’ so a little more patience is needed before the daily rom will contain a working XHCI driver for the Pi.

Not sure whether Director (supplied with RC16) works with the XHCI driver.

Once the Pi 4 is fully supported by RISC OS I think that will prompt a news item …

Question about HDMI: I just “accidentally” found that RISC OS boots on both HDMI connectors. Is dual monitor already supported, or is one HDMI connector chosen at boot? If dual monitor works, I would want to buy a 2nd micro HDMI cable.

So, I guess that the touch function of my screen isn’t compatible. I’ve asked the question of Waveshare, but I’m not sure whether they have any experience with RO.

Probably not but they might have some info that would help someone make a driver.

Their response implies that I just need a standard HID-multitouch driver.