Raspberry Pi 4

I don’t know if this is helpful or not, but I have been trying to setup another Pi 4 also powered by GPIO from an Element 14 Pi Desktop board, but using a different make of hub.

I had tried all sorts of settings in an attempt to get it to boot from an SSD or mSATA (on the Element 14 board or freestanding). All without any success. I gave up on this second Pi 4 and left it just with an SDcard to boot from.

Quite by chance, I was using this second Pi 4 to clear out the data on a 13 year old Weston Digital hard disc (power hungry spinning rust with external 5v/12v power supply).

Cutting out the middle bit of the story, I now have this second system booting reliably only from the WD HDD, whereas there is no way this Pi will boot from SSD or mSATA when using the same USB 3.0 hub (with or without any boot delay)

As before the CPU clock speed is set to 2000MHz.

whereas there is no way this Pi will boot from SSD or mSATA when using the same USB 3.0 hub (with or without any boot delay)

Answering my own point, I have now worked out that the order in which the devices (mSATA, keyboard ond mouse) are plugged into the USB hub is VERY critical.

I now have it working with RO booting from the mSATA on board the Element 14 Desktop. (Still running at 2000MHz with a cooling fan)

Maybe, all of this will become a lot simpler if I get myself a Revision 1.2 Pi 4 (without the USB-C hardware fault)

I have not cluttered up the RC16 topic in General.

Here seems a better place to say RC16 ticks along nicely at 2000MHz on a Pi 4 (subject to all the previous posts about RiscOS needing a suitable USB hub and, maybe, GPIO power)

Any news about the Pi 4 on board USB sockets? The first aniversary of the Pi 4 is very rapidly approaching.

I am still very happy with what I have – GPIO power and a external USB hub giving Keyboard, Mouse and SSD.

The first aniversary of the Pi 4 is very rapidly approaching.

It is only approaching here at the normal speed.

I am not sure whether anyone is working on this, nor whether there is a bounty for it. The task is allocated to ‘nobody’.

Here’s some praise for ROOL, et al. over the RPi4 port :-) RISC OS worked first time when swapping the SDcard and USB drive between a RPi4 4Gb and 8Gb model.

It was certainly a smooth process versus the trouble Linux gave me; eeprom and fstab issues, now solved.

Yes, as of the end of September, the RISC OS port for the Pi (RC16 plus a daily rom) works on all variants of the model 4.

Yes, as of the end of September, the RISC OS port for the Pi (RC16 plus a daily rom) works on all variants of the model 4.

So we now have a version that runs. Really good news. Does everything now work or are there still bits, e.g. some USB ports not working, or not working fully. I’ve rather lost track of progress.

Does everything now work or are there still bits, e.g. some USB ports not working, or not working fully

Raspberry Pi 4 port status gives a brief run-down of the current situation.

The page doesn’t mention one minor item (GPIO pull-up/pull-down resistor settings) that’s working its way through GitLab, but (a) it’s not a show-stopper, and (b) it should be resolved in the next week or so.

AFAICS the Pi 4 build is on track to be included in RISC OS 5.28, whenever that appears.

Neat! I didn’t realise that USB was working now (the commit description on 12 Sep doesn’t actually contain ‘USB’) so that’s good to know. I might have to actually buy a Pi 4 at some point now!

I might have to actually buy a Pi 4 at some point now!

This ^

so that’s good to know

Failing any other announcement, the fact that RISC OS now works on the Pi model 4 is the subject of an article in the next issue (25:1) of Archive.

Should that article contain a note that, at the time of writing, the USB ports don’t work in USB 3 mode? Remind people to check the ROOL site for updates on that.

Or did the USB 3 aspect get sorted and I missed that info?

Or did the USB 3 aspect get sorted and I missed that info?

The USB3 ports on the Pi4 now operate in USB 1/2 mode only under RISC OS and force a USB3 device into USB1/2 mode. RISC OS’ USB stack is too old to support USB3 without a lot of work.

It’s worth noting that a lot of money has been raised to finance the work to upgrade the USB stack. Just the developer required now…

RISC OS’ USB stack is too old to support USB3 without a lot of work

It’s sharing a status with the network stack, and the wireless and…

If I remember right one Michael G’s comments about the Pinebook Pro was regarding instability in the USB3 – any improvement will probably ripple across a few different boards.

Michael G’s comments about the Pinebook

I haven’t commented on that, I hope! It does have DWC USB ( however kbd and mouse pad is on ehci as well as one of the external ports) which is supported by Pi. In my old RK3288 hack I used a old version of the driver, with no pi specific bits. This was the unstable thing.

Please also understand that riscos port to pbp is nowhere nere something that you can call usable. As I have stated, my proof of concept for the sister board RockPro64 is just that , a proof of concept.

In my old RK3288 hack I used a old version of the driver, with no pi specific bits. This was the unstable thing.

Apologies, misremembered.

The page doesn’t mention one minor item (GPIO pull-up/pull-down resistor settings) that’s working its way through GitLab, but (a) it’s not a show-stopper, and (b) it should be resolved in the next week or so.

True, but this page does. It was committed 5 hours ago so should be in tomorrow’s daily build rom.

The StrongHelp file for GPIO 1.00 is still a little terse. On the Raspberry Pi I can set GPIO pins to input and output and read and write them. If I want to change their pull up/pull down my understanding is that they revert to their default status (GPIO 0 to 8 pull up, GPIO 0,1 physical pull up resistors, others pull down) on a reset or power off. Hence GPIO 4, just before the rom initialises on a restart, will be pulled high whatever its pull up/down setting may have been in the past. Thw Witty Pi relies upon this, as does my software power control circuit.

Prior to today’s change, the pull up/pull down routine did not work on any model of Pi. It should work on all models of the Pi after the change(?)

I now want to set (say) GPIO27 to be pulled high. I think the ‘GPIO’ mode is zero (low four bits in R1 for WriteMode) so that:

SYS "GPIO_WriteOE",27,1:REM set GPIO27 to input
SYS "GPIO_ReadData",27 TO a%
SYS "GPIO_WriteMode",27,&30:REM set GPIO27 pull high
SYS "GPIO_ReadData",27 TO b%
PRINT "GPIO 27 defaults to pulled low so read as ";a%;" s.b. 0"
PRINT "then reads as ";b%;" s.b. 1 after pull up status changed to up."

should do the trick?

Prior to today’s change, the pull up/pull down routine did not work on any model of Pi

A change was accepted a few weeks ago that made it work on models up to 3 (all variants). As from tomorrow it should work on all models.

A change was accepted a few weeks ago that made it work on models up to 3 (all variants). As from tomorrow it should work on all models.

It now works on the Pi4, the code now corrected as below:

SYS "GPIO_ReadMode",27 TO pin27%
IF (pin27% AND &1F)<>0 THEN ERROR 0,"GPIO 27 is not in GPIO (0) mode"
SYS "GPIO_WriteOE",27,1:REM set GPIO27 to input
SYS "GPIO_ReadData",27 TO a%
SYS "GPIO_WriteMode",27,&60:REM set GPIO27 pull high
SYS "GPIO_ReadData",27 TO b%
PRINT "GPIO 27 defaults to pulled low so a% is read as ";a%;" s.b. 0"
PRINT "then reads as ";b%;" s.b. 1 after pull up status changed to up."

This works and prints 0,1 after a reset, subsequent runs producing 1,1 until the next reset.

The port status of all platforms, with the exception of the ARMX6 which is administered by R-Comp and the IGEPv5 administered by CJE, has transitioned (as of 12 October) to green for RISC OS 5.28.

I just installed one of my my RPi 4 fresh from RC16 and replaced the RO image with the NB RO ROM from yesterday. Seems to work fine, but runs a lot hotter than previous RPi variants – a case with a fan and adding some heatsinks is highly recommended. The “official” RPi 4 case is far from ideal being completely closed.

So far so good, but a word of warning: the RC16-bundled HForm 2.75 seems to be broken, it wouldn’t allow me to format a brand-new microSD card in various card readers (“No harddiscs configured” or something like that). HForm 2.76 however from the current DiscImage NB worked fine.

Yes, 2.75 will ignore certain slots in multi readers.

The gitlab change log shows that version 2.76 will:

Change the loop scanning for SCSI discs to not stop if a LUN reports an error, only stop if the LUN is not present. This ensures that multi-in-one card readers that have empty sockets in the lower numbered LUNs (giving “Target error – not ready” errors) don’t cause the discs in higher numbered LUNs to be missed.

Also, based on an idea from Alan Adams, warn if it appears the user is about to do something silly. That is: formatting the !Boot disc or formatting the disc on which !HForm is running. Neither is illegal, but it may reduce the chance of someone who didn’t read the previous 9 prompts saying what’s about to happen to think harder before the 10th and final prompt.

RC16 can be updated to HForm 2.76 using PackMan.

It seems that RISC OS 5.28 has been ‘cast in tablets of stone’ judging by this post.

Or perhaps just that any new developments will be directed to 5.29? Not quite the same.

Or perhaps just that any new developments will be directed to 5.29? Not quite the same.

I think that Chris was pointing out that the source repository activity suggests v5.28 will be released as the new stable “imminently” as they say and so that part is “cast in stone” with all development now going into v5.29