Raspberry Pi 4

I think it’s fair to say that we’re mostly blocked by lack of documentation for the PCI (needed for USB) + Ethernet. I’m about to start work on some of the smaller things (GIC + UARTs), which should at least make things a bit easier for the other developers.

In theory it should be relatively easy for us to get the old DWC USB controller working, which is hooked up to the USB C socket – so if you’re happy to power the board via GPIO (or have a USB hub that can back-power via the USB C socket), then let us know so we can prioritise that.

so if you’re happy to power the board via GPIO (or have a USB hub that can back-power via the USB C socket), then let us know so we can prioritise that.

If one was going to try to power the RPi4 from a hub what if any is the implication of the wiring error that limits which USB cables would work. If I have it right then a “cheap” cable should do, as opposed to a “clever” cable which won’t.

I am not averse to trying stuff but USB C has not really arrived here yet, so no cables here ATM.

I do have RISC OS running on the RPi4 in a “can’t do anything with it sort of way” due to no USB but it does boot to the Desktop.

*USBDevices does show the Synopsys DWC OTG root hub.

An OS_Memory 8 call does show 1915MB RAM.

Is there support in any of the Pi BSD ports? I couldn’t see anything after a brief look, so maybe they have the same problem?

I assume the magic is all in Raspbian (Linux) so isn’t perhaps one option to clean-room the Linux implementation?!

Is there support in any of the Pi BSD ports?

Not that I’m aware of.

I assume the magic is all in Raspbian (Linux) so isn’t perhaps one option to clean-room the Linux implementation?!

Yes, that option is available to us. But we also know that better documentation is meant to be coming at some point, so it’s a bit of a toss up between putting in the extra time+effort needed for a clean-room reimplementation, or waiting for the documentation and doing something else useful in the meantime.

In theory it should be relatively easy for us to get the old DWC USB controller working, which is hooked up to the USB C socket – so if you’re happy to power the board via GPIO (or have a USB hub that can back-power via the USB C socket), then let us know so we can prioritise that.

If it means getting USB support sooner I’m happy to do that.
This cable seem to work ok to power the RPi4 from GPIO.

Here’s a screen shot from a 4GB Rpi4 showing free memory with a full sized ram disc.

Jeffrey said:

But we also know that better documentation is meant to be coming at some point, so it’s a bit of a toss up between putting in the extra time+effort needed for a clean-room reimplementation, or waiting for the documentation and doing something else useful in the meantime.

Totally makes sense. I would imagine that at least one of the ROOL guys will find out as the information is released from the Pi team.

I didn’t intend to sound flippant. I appreciate that there are very few people actually able and willing to contribute to these sort of things, and I really don’t want to sound like some sort of whinger. As far as I am concerned, these things will be done when they are done!

This cable seem to work ok to power the RPi4 from GPIO.

Hmm, that reminds me that the serial level shifter board I’ve been using with my Pi has a (previously unused) mini USB socket for powering the board. Connecting it up causes it to deliver 5V through the VCC lead, which is good, but also 5V for RX & TX, which is bad (in normal use I power the board by connecting VCC to the Pi’s 3.3V). I could probably go down a frankenstein route of using the serial level shifter to power the board, and separate jumper cables to a different Pi to get the serial terminal. Or maybe just jumper the 5V+GND from two boards together if I’m feeling brave with how strong my power supply is. But like David says, USB C hasn’t really arrived in my house yet, so if I want to do that I’d still need to buy an extra cable anyway.

Here’s a screen shot from a 4GB Rpi4 showing free memory with a full sized ram disc.

Ah, the Switcher needs fixing to cope with >2GB RAM.

I didn’t intend to sound flippant.

Don’t worry about it – your post didn’t come off as flippant to me.

I think it’s fair to say that we’re mostly blocked by lack of documentation for the PCI (needed for USB) + Ethernet.

Many thanks for the update – didn’t know there was a problem with the documentation.

Here’s a screen shot from a 4GB Rpi4 showing free memory with a full sized ram disc.

9 months on, all seems quiet. Any further on the RPi4 with Risc OS?

Not quiet at all, but for some reason it’s all sitting in the General forum rather than here in Porting.

It seems the Ethernet driver has been completed but the USB still requires the OTG port to be used and power supplied elsewhere. Not sure whether the standard Pi rom on the downloads page now copes with Pi 4 (excluding the on-baord USB sockets but using the OTG power plug and a hub).

Not sure whether the standard Pi rom on the downloads page now copes with Pi 4

The nightly beta development build has supported the Pi 4 for some time now. (as you say excluding the on-baord USB sockets but using the OTG power plug and a hub)

The Ethernet connection now works as well.

Just a quick one… Has the serial driver been updated to work with the Pi4. I believe the new SOC has 4 real UART’s now…
Just to clarify, I was looking at driving a Sprog for DCC control…..

I did have some changes to add support for the extra UARTs – I should probably tidy them up and get them submitted.

Jeffrey, does this mean the standard UART should work out of the box?
Do I need to mess with the GPIO to get it on to the original pins, as I believe it is now used to drive the Bluetooth chip.

Yes, the standard UART works out of the box on Pi 4.

Do I need to mess with the GPIO to get it on to the original pins, as I believe it is now used to drive the Bluetooth chip.

No. On both the Pi 3 & 4 the OS already remaps the pins so that the standard UART is used for IO.

The HAL also has some code for using the mini UART (currently it’s just a build-time toggle to select which one is used), so in the future we should also be able to support routing the standard UART to the BT chip and using the mini UART for IO.

Tank, you could always run your DCC layout direct from Basic. I demo’d a small test track running under DCC control at the RO London Show around five/six years ago. The program was in Basic V running single tasking on a Pi 2. Only used one GPIO line, IIRC, and a £2 L298 chip. Cheap as chips DCC in fact.

I toyed with it for a while afterwards and added extra code for points control and loco re-addressing etc. I was going to add turntable and transporter support but I got distracted by other stuff (like you do) and it didn’t get any further.

Haven’t looked at it for 3-4 years so I’ve lost touch with which bit of code does what and there are still lots of bugs, but as a proof of concept it worked brilliantly.

Thanks Jeffrey.
Neil, It will probably be in BASIC to start with.
I already have the Sprog unit, so that handles all the DCC communication and just needs commands sent to it.
I would be interested to see your prog though if that’s OK with you (webmaster@tankstage.co.uk).
The main reason I would like to do this is the fact that JMRI feels painful to use on the PI as its so slow.

Here’s a screen shot from a 4GB Rpi4 showing free memory with a full sized ram disc.

I also have a Pi 4 running using the PCB from an Element 14 desktop for power via GPIO and mSATA disc drive.

The on-board mSATA works via a USB 3 Hub connected to the USB-C port on the Raspberry Pi and looks quite neat using short USB cables for both connections.

As the main USB ports on the Raspberry Pi 4 are not powered up the board runs very cool (currently 42 degrees) at 1000MHz slow speed. I think I am likely to keep this setup even when RISCOS supports the on board USB 2/3 ports. The two boards do have a small silent Pi fan running from the 3.3v pins on the GPIO.

(Unverified) opinion on the ’net says that the Pi 4 is designed, with proper cooling, to run as 2GHz with all 4 CPUs and that with just one CPU switched on it is well within its capabilities.

So, worth a try I thought and edited my config.txt

over_voltage=5

arm_freq=2000

Very impressive and still only in the mid 40s temperature idle at 1000MHz and mid 50s prolonged load at 2000MHZ. It still has the fan.

I have a copy of Paul Vigay’s !USBtest program which he said can take over an hour to complete. With a RAM disc it was done in less than a second!

When running this Pi 4 at 2GHz with the on-board mSATA of the Element 14 Pi Desktop, I occaisionally found the boot failed with the message Waiting for boot drive to be ready

I needed a way to slow down the boot.

My solution is to set the Configure Filesystem to SDFS and add a Boot.Run obey file on the SDcard which changes the boot drive on the fly to access the mSATA. I use a copy of the standard Boot.Run file and replace the Set Boot$Dir line with

*SCSI

Set Boot$Dir SCSI::4.$.!Boot

The access of the SDcard during RISCOS boot is sufficient time to ensure the mSATA is ready, but does anybody have a simpler (and probably, neater) solution?

Waiting for boot drive to be ready

I ran into a similar problem with the Raspberry Pi 3B (also using the “Pi Desktop” mSATA). I had some success by increasing the “boot_delay” parameter in config/txt – sadly I cannot now remember what value I used (as I subsequently swapped out the 3B for a 3B+ which didn’t suffer from the problem at all). Anyway, it may be worth a try.

Thanks for that. I will give it a try tomorrow.

I have tried a delay of 300ms and still get problemsat boot time.

Setting the initial boot drive as SDFS is seems to avoid any problems, so there may be more to it than just the delay.