Raspberry Pi 4

I like the sound of that. Thank You. I will also keep my boot loader files on the Pi USB2/3.

Drive 4 is a GPIO powered mSATA card on the Hub.

I have got a Raspberry Pi 4 (4GB) going but the HDMI sound is dead. I have remembered to set ‘hdmi_drive=2’ in its config/txt file, so it is set to work. Any idea why it isn’t working please?
Using: RC16 2020-06-14 + Pi ROM 2020-09-20

Try adding the following to config/txt,

hdmi_preferred=1

Thanks Chris G. Just tried adding hdmi_preferred=1 to the config/txt file but the HDMI sound is still dead.
To confirm, my HDMI cable is plugged into the HDMI 1 port.

sound only works on hdmi next to the usb c port

The screen doesn’t work on HDMI 0, the port nearest to the USB-C port.
Setting hdmi_preferred=1 is supposed to set sound out of HDMI1.

sound only works on hdmi next to the usb c port

Agreed. certainly the case on this Pi 4 with 5.27 (29th August)

The screen doesn’t work on HDMI 0, the port nearest to the USB-C port

Interesting. The screen works on either of my HDMI ports. (5.27 29th August)

I have no hdmi settings in config.txt.

Maybe, it depends on where the build comes from? My RISCOS/IMG file, built by Sprow, is 5M in size and the file is dated 05 SEP (but the switcher icon says 29th August)

EDIT: (15 hours later) Retested with nightly build 20th September and statements about HDMI found still to be true.

Thank you for your replies. I have gone back to no hdmi_ settings in config/txt, plugged the HDMI cable back into HDMI 0 and the screen and sound now works! When I first switched on the Pi4 with new micro-sd card the other day with HDMI cable plugged into HDMI 0, all I could get was a black screen with a monitor message saying there was no input. I tried several times after checking the cable with just a black screen. I was using the original config/txt at the time, with no hdmi_ settings. That’s why I plugged the HDMI cable into HDMI 1 instead, which is how I got the screen to work.

So it seems that hdmi_preferred=1 and hdmi_drive=2 do not appear to work. I also notice the headphone socket has no sound coming out of it, even if hdmi_drive=1 is set. If hdmi_drive=1 is set there is no HDMI sound either.

Using: RC16 2020-06-14 + Pi ROM 2020-09-20 – now with HDMI cable in HDMI 0

Hey. Have we got any new builds?
Also, has Jeffrey Lee’s multiprocessor support been carried over to the Pi 4?

Tristan, there are nightly builds – I’m currently running the image and HardDisk4 from Sept 13.

Bernard, I have audio and video from the HDMI socket nearest the USB-C socket. No mods to the config, other than “disable_overscan=1”.

According to the RISC OS config.txt wiki page for the Raspberry Pi, hdmi_ignore_edid_audio=1 Force the audio to use the stereo audio jack output. I know it works on the Pi3, but unsure about Pi4.

Peter – Thanks – As I mentioned above, I have now discovered that. HDMI 0 is the socket nearest the USB-C port and my screen and audio now decides to work in it. I already had disable_overscan=1 in my config/txt file thanks.

Alan – Thank you for hdmi_ignore_edid_audio=1 to force the audio to the Pi audio socket. It works on the Pi4.

not sure if this is the right place to post this but if you are looking for a case for the RPi4 this might be worth further consideration:
https://deskpi.com/products/deskpi-pro-for-raspberry-pi-4
I ordered 1 yesterday in anticipation of getting the RPi4 soon – plan to run a Linux and try RISC OS on it perhaps with an Micro SD Card switcher like this one:
https://thepihut.com/products/2-in-1-sd-card-dual-system-switcher-for-raspberry-pi

good exchange for usd in aus so ordered one too

You can get the best of both worlds by keeping the hub on the USB-C socket.

It was all working very well until the micro-USB connector fell off the back of USB Hub board. It turns out the mounting pins were not soldered and I doubt if my hands are now steady enough to solder them on.

Fortunately this is my second Pi 4 and the other one is still working although inspection tells me not to play with the hub.

Also fortunate is that this Pi 4 can now be used without the hub.

EDIT: with aid of a vice to hold the hub and solder, I managed to solder the moounting points of the socket back on. (The electrical connections had not broken and held the socket in place whilst I did the soldering)

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

Also fortunate is that this Pi 4 can now be used without the hub.

The mouse worked much better using the hub on the OTG port. On the native USB3 port drag and drop has become drag and random drop, so I will be buying another hub (despite the failure of the orginal as described above)

Bryan, my mouse/keyboard combo is plugged into one of the USB2 ports and I have no issues with it. I’ve just tried dragging a file around the screen for a couple of minutes and it never dropped.

Edit. I’ve just plugged the mouse directly into a USB3 port and tried the same exercise, again without problem.

@Peter, thanks for the comments, which prompted me to change the mouse for one that works.

I have just had another mouse fail (tested on two Ras Pi 4s).

The reason I mention it here is that failure mode made the Pi 4 as good as useless. I think the system must have seen the mouse generating a fairly continual data stream because everything became very eratic. Even trying to access the system via VNC was an uphill struggle. Unplugging the mouse cured everything.

Since using RISC OS on my Raspberry Pi 4, including with all the recent updates, it takes me several attempts to get it to arrive at the desktop successfully. When it fails it gives a varying error message at a different point before the desktop arrives. If Ctrl/Break doesn’t yet work I have to switch off and start again. After 3 or 4 goes it then reaches the desktop OK without error. Using RISC OS thereafter it all works as expected and doing a shutdown and restarting without switching off also works fine. It’s just the switch on starting that goes wrong. Is this a known problem? If not, why is it going wrong for me please?

Bernard, your problem sounds to me like a really good example of why we need logging of system errors starting with the ROM section of the boot. (Hold in memory until the file system is in a state to put the initial log items to a permanent store)

That said, is the error something that occurs during the disc based boot and what errors are logged if you put Rick Murrays Harinezumi into the Boot?

It is suggested that RISC OS 5.28 on the Raspberry Pi uses the June 2020 firmware from the Raspberry Pi Foundation. Not sure if that makes any difference at all, but thought I’d mention it just in case.

It’s just the switch on starting that goes wrong. Is this a known problem?

That is very odd, there is some instability somewhere, somehow, at start up and once started it’s OK.

The only thing I can think of is is the power supply not quite good enough and that really is just a guess. Is the power supply the official Raspberry Pi 4 job or something else?

Out of curiosity I downloaded the RISC OS Pi SD card image, utilised a new SD card and an 8Gb Pi4 to test the new image.

Attempt 1. Using the RPi imager (Raspberry Pi OS) and by selecting the custom OS option and I wrote the image to the SD card. Powered off. Restarted.

Result: Stuck at firmware screen. I discovered the RPi imager just wrote the RISC OS img to the SD card.

Attempt 2. Copied the RISC OS.img from the SDcard to Downloads and using the RPi imager again to write to the SD card. Restarted and I arrived at a RISC OS desktop.

Since using RISC OS on my Raspberry Pi 4, including with all the recent updates

What’s your approach? Steps taken…? Also if you made a note of them, the actual error messages might shed some light on what’s happening.