Raspberry Pi 4

Samsung EVO+ cards are the best for the Pi, with SanDisk Extreme a distant second.

My Pi4 4GB is now running RC16 plus latest ROM OK.

I’m just using the standard 2GB image so will look to expand the card capacity later.

One thing for me to get used to is that my Pi4 case is fitted with a fan and it makes a bit of noise!

I’m experiencing issues with several applications, running the Sep 13 nightly ROM. I don’t know whether these issues are inherent in the applications, expected shortcomings in the current state of the development build, or problems due to the Pi4 hardware.

I’m not sure, therefore, whether it is worth reporting these issues to a) the ROOL development team, b) the application author/maintainer or c) simply ignore them until a genuine 5.28 release. In many cases, the application simply bombs out on, or soon after, startup. These include NettleSSH, Hearsay, XAT’s HID driver (could be due to immaturity of the USB driver?). The oddest problem is with ObjAsm, which simply fails to carry on processing the source file after a successful GET directive (unless I’m doing something stupid after 13 years away from RO!).

Any thoughts/advices?

Oh, I’m very happy that my lprDriver (distributed by RComp), last built on my Iyonix in 2005, still works perfectly on Pi4/5.27, especially since it messes with the system stack in order to achieve multi-threading/re-entrancy/multi-tasking!

Please report any issues with the daily rom under RC16 as that is the model (AFAIK) on which the stable 5.28 release will be based.

Where the applications are bundled with RC16, then you should report both to the Bugs forum (and thus to ROOL) and to the author using the contact details supplied with the application. Where not bundled to the author. If the application worked on the same machine with an earlier rom, then also to ROOL but not otherwise. Make sure you identify the version of the application and of RISC OS and the HardDisc4 source (for RC16 the last two are implied).

User feedback is essential – without it there will not be a stable release!

I have tried an 8GB build using the current beta source plus long descriptor components from here. There is an error on quitting the RAM disc.

*FX0
RISC OS 5.27 (31 Aug 2020)

Build date    : Mon,31 Aug 2020.16:42:05
Platform      : Raspberry Pi 4 Model B
RAM 7995MB

*where
Address &FC01D754 is at offset &0001D754 in the Kernel

Thanks for the report; this should be fixed now (I’ve also updated the HAL + Kernel LongDesc branches to contain the latest changes from the main repos).

The primary cause of the failure was a bug in the long descriptor code, but the investigation of that also led to the discovery of a few other bugs lurking in the normal kernel.

I’ve also updated the HAL + Kernel LongDesc branches to contain the latest changes from the main repos

Many thanks, I have got that built. RAM disc quits without error. 8GB, XHCI including USB3 ports seeing USB3 devices, looking good.

The card that worked in the Pi4 was actually an older Samsung evo 16gb card! I will look into where SDIO driver hangs at a later date, as I think it can be fixed which will help when RO gets back with an official release for the Pi 4 :)

Regarding the USB on Pi4, the test rom was crashing a lot especially when reading from USB thumb drives. I don’t know if that,is the case with the latest RC16 but will try; I stayed on the non-XHCI due to crashing – hard lockup often around USB flash drives, to the extend that vncserver was frozen.

Can someone summarise what if anything essential is left to do for the Pi4 port?

Will the Pi4 USB updates be added to RC16 by ROOL?
or if possible and appropriate could some kind soul do an RC16 build adding Pi4 USB?

Can someone summarise what if anything essential is left to do for the Pi4 port?

I’ll give it a go.

Essential:

• Fix lockup (or AODT) when moving a USB hub
• Fix GPIO pull-up control (if it hasn’t already been done)

Desirable:

• Sort out the “2GB free memory” issue (e.g. SparkFS fails on 4GB and 8GB models)

I may have missed a few, of course.

if possible and appropriate could some kind soul do an RC16 build adding Pi4 USB?

It’s pretty easy to do it yourself.

Thanks for the very encouraging info.

It’s pretty easy to do it yourself.

I have the motivation but not the skill or time to do it:-(

I have the motivation but not the skill or time to do it:-(

That made sense until 13 Sept. From then it does not. The RC16 image is all that you need for all models of Pi except the Pi 4. The only difference on the Pi 4 is that you should replace the rom with the daily build. A simple

*copy [source] $.!Boot.Loader.RISCOS/IMG

The barrier is therefore now as low as it can be.

So far as ‘the other things to do’ are concerned – they do not prevent RISC OS working on the Pi4 and will not happen immediately. They should not cause any serious issues unless you need to use the GPIO system for a very specific and complex purpose or want to use an unsupported USB device, of which there will always be a few.

The only complication is that you can’t do this copy operation under RISC OS on a Pi4 ….

At least, not the first time. But once you have it running, you can update it.

Alternatively, you can boot RC16 directly on a Pi 4 if you use SDIO power and a suitable USB Hub plugged into the USB-C connector as described around July 8th in this thread. Then you can update it as above to no longer need the SDIO power and hub. (or, you can keep them and have 8 working USB ports on a fan cooled Pi4!)

To make an RPi4 variant of RC16 on a Mac.

Download RC16 and the Beta Pi ROM.

Flash RC16 onto an SD card with balenaEtcher. The card is dismounted at the end.

Remount the SD card, pull it out and reinsert it.

The FAT partition can be seen in the Finder.

Replace the RC16 RISCOS/IMG with the copy from the beta Pi ROM.

Dismount card.

Put card in RPi4.

Worked here!!

This can probably be done on Windows or Linux.

It may be possible on Raspberry Pi OS, I have not looked at that.

I have the motivation but not the skill or time to do it:-(

Did you actually read the page Stuart kindly linked you to? The only “skill” required is downloading files (the links to the files are given), and dragging then to the SD Card you’ve written. Even if someone else did this for you, you’d still have to download the image and write the SD Card, so the only extra skill is dragging a file, which surely you must be able to do??

or time to do it:-(

Lots of people on here are also very busy people, who’s time is probably better spent elsewhere rather than foillowing very simple instructions to make SD Card images for other people.

If you have the motivation, you’ll find the time.

Fix GPIO pull-up control (if it hasn’t already been done)

The modified files are awaiting further review. I think I’ve just prodded the reviewers again.

Thanks for the clarifications. Glad to see a way is available to get a Pi4 compatible SD image is available to mere mortals. Having asked about building the sources being told “It’s pretty easy to do it yourself.” meant I didn’t look further.

Having asked about building the sources being told “It’s pretty easy to do it yourself.”

Well, it is if:

1. You have a recent copy of the DDE (some changes in the source mean some elements fail with, for example, DDE v24). No DDE – show stopper.
2. You follow the wiki pages on setting up !Builder using a downloaded set of source and your copy of the DDE, with a bit of interpretation. It isn’t quite a basic, basic level guide.
   Oh, and the setup with header, library and resource extract will take a while so start that and do some gardening, popping back occasionally. The extract only needs doing once so those tick boxes are blank in future build jobs.
3. You read the wiki pages on building your own. Then re-read with a bit of interpretation. It isn’t quite a basic, basic level guide.
4. You have a lot of patience and can wait a fair while for the build to complete – you thought the header etc extract was time-consuming? Well…

So, yes, I’d go with your stance of not building your own.

My experimentation is limited to tweaking a module or two and building those as soft-loadable items, which I suppose is the only real way to experiment and test.
Full ROM build? Nah, not unless I absolutely have to, and Pi4 would have to wait for the grand clearance of “the computer room” (bedroom 4) and the construction of a suitable test bench.
By that time there will doubtless be another brand-new Pi board.

It’s old so some bits are out of date, however…

https://heyrick.eu/blog/index.php?diary=20131105

So, yes, I’d go with your stance of not building your own.

Fortunately, no-one was suggesting that Tim build his own ROM… only his own SD Card image, which is what he seemed to be asking about doing.

The page linked to described how to update an existing RC16 card image with a ready-made ROM image from the current code from Git, as prepared overnight by the ROOL autobuilder. We have computers to do these things, so that we don’t have to. :)

Fortunately, no-one was suggesting that Tim build his own ROM… only his own SD Card image, which is what he seemed to be asking about doing.

Clearly I failed to explain sufficiently.
I know Tim was asking about the update, it was his side reference to the ROM build he’d previously been advised was easy I was commenting on.

I quite liked Rick’s reference to his old blog item about the builder setup and use. It’s a saga.

Sort out the “2GB free memory” issue (e.g. SparkFS fails on 4GB and 8GB models)

Are people still having trouble with SparkFS? Are you running the latest version?

I was planning on looking into some memory corruption that occurs when it fails, but annoyingly I now seem to be unable to get it to crash. The best I can do is get 1.43 to report “not enough memory” on startup, which renders it unable to open archives, but no outright crashing.

1.45 seems to be fine, and looking at my original notes, I think it only ever was older versions where I ran into problems.

Sort out the “2GB free memory” issue (e.g. SparkFS fails on 4GB and 8GB models)

Are people still having trouble with SparkFS? Are you running the latest version?

I am running an 8GB RPi4 and I have not seen any problems with SparkFS 1.46 (06-Jul-20).

Are people still having trouble with SparkFS?

I had been relying on your earlier comments when I made that post: I’ve not seen SparkFS fail myself.

I can confirm that SparkFS 1.46 read/write works as expected on a 4GB Pi4 using the 13 September 2020 ROM.

I have 2 Pi4s both running RC16 with the USB test ROM dated earlier this month.

They both have GPIO power from an add-on board which also has a very good cooling fan which I intend to keep.

My question is about the GPIO powered USB hubs which are connected to the USB-C socket on the Pi4. I am Asuming that when 5.28 is released that the USB functionality of the USB-C power socket will be kept. But what are the advantages/disadvantages of continuing to use this rather than the native USB2 and USB3 sockets on the Pi4?

what are the advantages/disadvantages of continuing to use this rather than the native USB2 and USB3 sockets

Advantages: The OTG port will support a wider range of USB devices (it won’t be quite as picky as the XHCI driver).

Disadvantages: There are certain restrictions in terms of device combinations that only affect OTG ports. For example, you are limited on the number of USB1.1 devices you can attach to a single-TT USB hub.

You can get the best of both worlds by keeping the hub on the USB-C socket but moving the mouse and keyboard to the native USB2/USB3 ports.