Raspberry Pi 400

It would be more helpful to post a resolution, but ….

Commenting out a few lines seems to resolve the failure of the SD card slot to activate. (Best to consider this as Work in Progress for now.)

--- ADFS::ROOL.$.ROOL.RPi400.BCM2835.RiscOS.Sources.HAL.HAL_BCM2835.s.SDIO_00	2020-11-08 19:03:59.0 +0000
+++ ADFS::ROOL.$.ROOL.RPi400.BCM2835.RiscOS.Sources.HAL.HAL_BCM2835.s.SDIO	2020-11-08 19:03:59.0 +0000
@@ -409,4 +409,4 @@
         TEQNE   a3, #BoardRevision_Model_Compute3
-        TEQNE   a3, #BoardRevision_Model_Compute3Plus
-        TEQNE   a3, #BoardRevision_Model_Compute4
+;        TEQNE   a3, #BoardRevision_Model_Compute3Plus
+;        TEQNE   a3, #BoardRevision_Model_Compute4
 02      ; So now LO => model A or B, EQ => Compute or Compute3, HI => A+, B+ or Pi 2 or Pi 3 or Pi 0 or Pi 4
@@ -434,4 +434,4 @@
         TEQ     a3, #BoardRevision_Model_Compute3
-        TEQNE   a3, #BoardRevision_Model_Compute3Plus
-        TEQNE   a3, #BoardRevision_Model_Compute4
+;        TEQNE   a3, #BoardRevision_Model_Compute3Plus
+;        TEQNE   a3, #BoardRevision_Model_Compute4
         BNE     %FT10

Is the keyboard ok, or is it as bad as the one from PiTop?

No, it’s not THAT bad, but in my opinion, it’s not great. Especially not for RISC OS use. F12 from Fn and F2 isn’t useful, and no Break key (or anything useful to map it to, except possibly PrtScrn which would normally work as Print) is a bit dire. There really isn’t much travel on the keys. I guess, given the price difference, it feels like a $15 keyboard. And not a great one at that. IMHO.

Commenting out a few lines seems to resolve the failure of the SD card slot to activate.

The issue is reproducible on the RPi4.

A sort of early Xmas present. Have fun. Lots of new coding.

Definitely sir! super happy with the Pi 400, it’s very cool and works fine (when overclocked) also with my linux, so super excited, been off-line all weekend playing with it! :)

Things were going well until I looked for the headphone socket. Any tips for getting sound working? Nothing on HDMI, also tried an hdmi→vga+3.5mm splitter without success. I also looked at using a cheap usb audio adaptor, but if that is possible I haven’t got very far yet.

I’m running a RISC OS Direct image plus Chris Hall’s ROM from the 5th, if that makes a difference. Been away from RISC OS for a long time, so apologies if I’m doing something stupid or if this is a bigger issue covered somewhere I’ve missed. Fwiw thanks to you all for doing an amazing job.

Re the keyboard, I really like it; it’s a membrane chiclet with quiet click, and is very similar to my Cherry KC 6000, which cost about the same as the entire RPi 400. I think they’ve done well to put such a nice keyboard in such a budget-conscious product. That said, it is still a membrane chiclet, so if you prefer the full depth clack of the BBC/A3000, then this probably isn’t for you. The lack of F12 and a break key has already been an issue, so it’s not perfect, but am guessing there’s a way around that which is short of persuading RPi to do a keyboard with 12 F keys in red.

By default, if the Pi 4 detects a monitor capable of audio over HDMI, then it sends it that way. Otherwise it sends it over the audio jack. The Pi 400 has no audio jack. This can be overridden by config.txt (I don’t mean that an audio jack will mysteriously appear on the back of the case if you say the right thing in config.txt, or perhaps I do …).

Any tips for getting sound working?

Sound works on the RPi4, with or without hdmi_drive=2, but not on the RPi400. There may be conditionals in the HAL or VCHIQ to be resolved.

Sound works on the RPi4, with or without hdmi_drive=2, but not on the RPi40

Maybe I misunderstand, but sound is working here, over HDMI, on the Pi400. I didn’t do anything in particular – it just worked!

I didn’t do anything in particular

That is exactly what I did, but it didn’t just work. Still no sound. How very odd.

That is exactly what I did, but it didn’t just work.

Swap the details of your HDMI displays guys – there may be a known quirk of yours (David) just waiting to be found on the net. Can’t be wong to check…

Ah, I have sound!

I played with config.txt to no effect, but it then occurred to me that I’ve been consistently trying everything in the same hdmi socket – the one next to the usb c socket.

I moved over to the one next to the micro sd slot and sound now seems to be working, albeit with some mild lag in some apps.

No changes required to config.txt.

That’s the one I use with my AOC 2577PWQ monitor. I’d assumed the other one just wouldn’t display anything. Last time I tried it, I just got the rainbow.

No lag here, though.

Ah, I have sound!

I played with config.txt to no effect, but it then occurred to me that I’ve been consistently trying everything in the same hdmi socket – the one next to the usb c socket.

That’ll be me too.

I have two monitors, and better still two micro HDMI leads, and using Raspberry Pi OS it can be seen that HDMI1 is by the SD card and HDMI2 is by the USB C connector.

With both monitors connected RISC OS only uses HDMI1 with HDMI2 showing the rainbow square. With only one monitor at power up either HDMI socket will show the desktop but only HDMI1 has sound.

Sorted! Thanks very much.

Any tips for networking?

Each time I boot I hit “Contacting DHCP server for Ethernet over USB interface” – assumed it as because I didn’t have a network cable plugged in, but now I do, I’m still getting it.

The workaround listed here doesn’t work – Network → Internet → Interfaces returns “No network interfaces were detected”.

usbdevices lists 5 items (3 hubs, keyboard and mouse). Am I missing a module or something? (Using the RO direct image plus a rom from this thread)

usbdevices lists 5 items (3 hubs, keyboard and mouse). Am I missing a module or something?

On the Pi 400, the Ethernet interface doesn’t connect via USB at all.

Check that *Modules lists “EtherGENET” (it should be at or near number 97 in the list). Also issue *Unplug to check that the module isn’t unplugged.

Hmm, EtherGENET is there, EtherUSB right below. Tried unolugging the usb one but it didn’t help. Perhaps I’ve got myself in a pickle using risc os direct and haven’t upgraded something properly?

Perhaps I’ve got myself in a pickle using risc os direct and haven’t upgraded something properly?

RISC OS Direct is a bit out of date. Specifically it is missing an ‘Autosense’ file that detects the presence of the EtherGENET interface. Updating !Boot should sort that out.

Perhaps I’ve got myself in a pickle using risc os direct and haven’t upgraded something properly?

If you have used your SD card in a non-Pi 4/400 machine then moved it to a Pi 4/400 machine (or vice versa) you will need to delete the directory !Boot.Choices.Boot to repopulate it. Otherwise it will use Ethernet over USB or Ethernet over GENET, whichever worked first and will never try the other. This applies to RISC OS 5.28, 5.29, the ROOL distro and the Direct distro.

Oh, just updated my web site – update 14 – with a rom that works on both Pi 4 and Pi 400. RISC OS 5.29 (11-Nov-2020) is how it announces itself in the switcher on both machines. If you do *FX 0 from the command line then it reports itself correctly on the Pi 4 but reports itself as ‘(number)’ on the Pi 400. Same rom, same SD card. Most odd. The rom compiled with no errors using the changes to the source files that are waiting to be merged.

Commenting out a few lines seems to resolve the failure of the SD card slot to activate.

I’m having difficulty reproducing this here. Just in case, can you confirm you’re using the same card to boot, whether you’re using a ROM with and without this change, to rule out hardware differences (e.g. different-speed cards)?

By contrast, I’m finding booting from SCSIFS to be extremely flakey in general, and that’s both with and without your patch. It generally seems to be OK until we enter the desktop, but then hangs. Sometimes it responds to Escape keypresses and pops up a “Disc not present” error box.

I’ve tried unplugging both SDIODriver and SDFS, which (a) means that the only code from the HAL which actually touches the SD hardware which actually executes is the function that sets the voltage regulator to 3.3V, and (b) means that any stray canonicalised references to SDFS::RISCOSpi should have complained about the filing system name, not the disc name. I still get the same error, which suggests to me that the problem is caused by intensive use of SCSIFS – maybe an interrupt hole in the XHCI driver, since that’s the bit of the USB mass storage stack that’s changed since earlier Pi models?

On those occasions when I can get to a command line (e.g. by hammering Escape during the early part of the boot sequence) I can bring up SDIODriver and SDFS and access the SD card just fine. So what’s different for you?

I am using the source changes which are awaiting merging (see http://www.svrsig.org/software/Update.htm for the rom in update 14) and have no problem with SD card on the Pi 4 or the Pi 400. With XHCI many marginal pen drives and hubs will fail. The driver cannot adjust itself to accommodate them as it is done in hardware in XHCI according to Rob.

I’m having difficulty reproducing this here. Just in case, can you confirm you’re using the same card to boot, whether you’re using a ROM with and without this change, to rule out hardware differences (e.g. different-speed cards)?

I’m not using an SD card to boot in to RISC OS. Just a USB attached SSD formatted with SystemDisc.
The easiest way to reproduce it is to put the SD card in a USB adapter. The Rpi 400 will automatically boot from it. Make sure there is no SD card in the SD card slot. With a ROM built with your changes in GitLab, placing an SD card in the SD card slot after booting into RISC OS always gives ‘The disc drive is empty’. Using David’s ROM instead the SD card is detected as normal.

I am using the source changes which are awaiting merging (see http://www.svrsig.org/software/Update.htm for the rom in update 14) and have no problem with SD card on the Pi 4 or the Pi 400.

Starting up the update 14 ROM on a USB stick and with no SD card in the slot the boot stops at a command prompt. Insert a card enter the desktop and clicking on the SD card icon results in the “The disc drive is empty” message. The ROM is fine used conventionally. Only booting from USB reveals the issue.

I’m having difficulty reproducing this here. Just in case, can you confirm you’re using the same card to boot, whether you’re using a ROM with and without this change, to rule out hardware differences (e.g. different-speed cards)?

Using a ROM that includes the RPi400 additions in the merge request. The issue shows when booting from a USB pen. USB boot only happens if the SD slot is empty. Having got to a command line start the desktop, insert a card and clicking the SD card icon always reports “The disc drive is empty”.

This does not happen with my ROM of the 05Nov20, but then that does not know anything of the CM4.

By a process of elimination it was found that commenting out the lines as reported earlier did allow the a build based the merge request code to be able to see the SD slot. Again that would not do a CM4 any good.

By contrast, I’m finding booting from SCSIFS to be extremely flakey in general, and that’s both with and without your patch.

I have not made much use of booting RISC OS from SCSI so far, but have not seen any issue. I will try that some more.

Currently the RPi400 is running on a partitioned SD card.

The USB boot followed by no SD slot was pointed out to me by Chris G.

Before the SDIODriver crash was fixed I did use a two pen solution, one Fat32 with the Loader contents sand the other SCSI with RISC OS, that worked just fine.

OK – it wasn’t clear that you were loading the firmware and OS from USB, not just running the boot sequence from it. That was enough to reproduce it, thanks. I reckon I’ve identified your problem, though running the boot sequence from the USB pen drive I was using before still fails. (It boots fine using an SD card in a USB card reader though, so it’s a device-dependent issue.)