Raspberry Pi 4

It has been moved north by about 30 minutes (car) or much more than that (public transport).

I didn’t think the old venue had a public transport link

The only issue I had was that after plugging the hub into the USB C port on the RPi4 the Pi failed to power up. But after slowly pulling the lead out of the socket at a certain point the Pi powers up.

So the idea is to have the good ROM, the right USB Ethernet interface reference and a suitable USB Type-C dock. Right?

I have a Pi4 waiting here and this: https://www.amazon.fr/gp/product/B06ZY1ZJDQ

So, if someone gives me the content of the FAT partition, I could try.
My 60W PSU should be enough :)

I am also waiting for someone to provide the rom for the Pi4 as the instructions to make my own rom are too obscure to follow as there is no source tarball to download. Instead it is all git nonsense.

The same post mentions ADMtek USB To LAN Converter and Realtek USB 10/100/1000 LAN adappters. A heads up on a particular working device would be good.

The ADMtek one has a Pegasus chipset which is supported. I’m not sure if these are still freely available. Ones based on the Realtek chip set aren’t supported.

Search on amazon for ‘USB 2 lan adapter’. Then look for one that says wii compatible and mentions the chip set AX88772A.

I have just built Pico for the RPi4. (While waiting in for Amazon to deliver parts to get the OTG port going.)

It’s straightforward to build a Pi4 compatible rom with working OTG port using just RISC OS and not having to use git.

First download the source tarball for BCM2835Dev from here.
Grab the Pi4 branch from here. There’s a button in the top right of the screen to download it as a zip file. The folder HAL_BCM2835-Pi4 in the zip replaces the same folder in RiscOS.Sources.HAL. Delete the existing HAL_BCM2835 folder and extract the HAL_BCM2835-Pi4 folder from the zip and rename it back to HAL_BCM2835 in the RiscOS.Sources.HAL folder.

The HAL_BCM2835-Pi4.zip must be unzipped with command line unzip available from here. This ensures the filetypes are set.

There’s another required change that hasn’t reached the BCM2835Dev source tarball yet. The patch file for it is here.

To apply the 1/diff patch download ‘patch’ from here.

Copy the patch file 1/diff into the RiscOS.Sources.HWSupport.USB.Controllers.DWCDriver folder. Open a task window in this folder and type ‘patch -p1 <1.diff’. (If running ‘patch’ on a Pi3 the ‘patch’ command will need patching with !PatchSWP)

Also the VCHIQ changes to fix sound and mouse pointer will appear in tomorrow’s source tarball.

Building the rom from scratch using a ram disc on a Pi4 @2.147 GHz takes 2m 15s.

Many thanks. With one exception the instructions are clear and I should be able to generate the rom.

This may seem ignorant of me but ‘the patch file for it is here’ sounded simple but looking at the file I am perplexed as to what to do with it. How do I run the patch file – it is not in BASIC nor command line. So it needs compiling but I don’t know what language it is in (it downloads as pure text with no filetype). It seems to be corrections to a source file but it doesn’t say which one! Can I just ignore it?

Please help (or are you just teasing me?).

Please help (or are you just teasing me?).

I’ve updated the instructions above with everything needed.

Building the rom from scratch using a ram disc on a Pi4 @2.147 GHz takes 2m 15s.

According to benchmarks here http://www.svrsig.org/HowFast.htm that’s a shade over 60% faster than a Titanium*. Hmmm….
[*3m 38s using RAMfs]

I’ve updated the instructions above with everything needed.

Many thanks. Just got back from the pub. I’ll let you know whether they were idiot proof!

The instructions were fine – 9min 11sec on an ARMX6 from SDFS. The suggested power through USB hub does not work – it barely lights the red LED but not the green, if you fiddle with it and have it part wthdrawn. The proper charger does light both red and green LEDs, but just leads to a blank screen. I then found that the file CONFIG/TXT had got itself corrupted so I corrected that. I also added a cmdline/txt file with disbale_mode_changes in it. Now I need to knoeck out StartUpNet to stop it waiting for DHCP. With that done, it starts up OK to the desktop.

The next step is to construct a ‘Hat’ which supplies power via the 5V header pin so that the OTG port can provide USB ports via the adapter which is unable to supply power itself (once I have commented out line 70).

This is a breakout board with power control, battery monitor, OLED, GPS and ‘on’ and ‘off’ buttons based around a 74HC00 chip. It will coexist with an Elesar WiFi Hat with 8 GPIO lines still free for a data monitor.

Many thanks for the help.

The suggested power through USB hub does not work

Is that the hub I pointed out? If so I may as well cancel mine.

I can confirm that Line 70 in RiscOS.Sources.HAL.HAL_BCM2835.s.USB is a problem, with that commented out the OTG port is now working. Thanks for that tip, I would not have worked that out for myself.

Power to the RPi4 is via GPIO with a USB to TTL lead, connected to the charging USB socket on an AOC monitor. It is not quite adequate, the undervolt flash has appeared. The USB hub is a simple unpowered 4 way device.

Wired Networking works over a Maplin USB to Ethernet dongle, that was briefly used with the RPi3B+.

Power to the RPi4 is via GPIO with a USB to TTL lead,

Ok so I could power the pi with a bench power supply. Do you have to fiddle with the usb c hub plug to get the hub working?

Do you have to fiddle with the usb c hub plug to get the hub working?

Don’t know yet. I assume not and that it is to do with the flawed Pi4 circuitry for controlling how much power it draws from a charger.

No. It just works.

Sorry. The question was for David. I want a pi with at least ethernet so I can use vnc./lanmanfs/sharefs. I don’t want to have to fiddle with plugs to get usb working. If his hub just plugs in and works I’ll get that hub.

Do you have to fiddle with the usb c hub plug to get the hub working?

No, not at all, that’s just fine.

The USB to Ethernet dongle contributes to the undervolting. Connecting that via an additional powered USB A hub looks to reduce the incidence of undervolting, as very briefly tested.

Networking is OK, NetSurf sees Google and ShareFS sees the Titanium, also as very briefly tested.

I can confirm that Line 70 in RiscOS.Sources.HAL.HAL_BCM2835.s.USB is a problem, with that commented out the OTG port is now working. Thanks for that tip, I would not have worked that out for myself.

Unless you were unlucky and downloaded the updated HAL and older DWCDriver submission in the time it took me to go to the loo, that doesn’t sound right. The two go together as a pair (I realised overnight that my first go at DWCDriver encoded knowledge of the interrupt number in a register offset, when really the HAL should be the holder of that knowledge).

I am waiting for a RISC OS ROM image to be made available. It’s taking much longer than expected…

In my best Terry Wogan voice: there’s one simple way to make things happen faster and that’s to put some bank notes in the jar. So if you like using the Pi 4 too, don’t forget to donate towards the porting effort!

In my best Terry Wogan voice: there’s one simple way to make things happen faster and that’s to put some bank notes in the jar.

There has been no suggestion (until now) that money would help. It was supposedly a lack of information. There is also no bounty for the Pi4 port.

The two go together as a pair

I did acquire the two at different times so I think I can see what went wrong. Thanks.

I’ll do my corrections tomorrow.

I don’t want to have to fiddle with plugs to get usb working. If his hub just plugs in and works I’ll get that hub.

If you’re providing power via GPIO pins another option is to use a USB C to Type A adapter. That way you can plug in a non USB C hub. Works out cheaper too if you already have the hub.

According to benchmarks here http://www.svrsig.org/HowFast.htm that’s a shade over 60% faster than a Titanium*. Hmmm….

That’s one of the things with the least amount of speed improvement. Most things are twice as fast at 2.147GHz.

If you’re providing power via GPIO pins another option is to use a USB C to Type A adapter

Yes that’s what I decided to go with as I already have powered USB2 and USB3 hubs.

Most things are twice as fast at 2.147GHz.

I wonder if there will ever be a Pi clocked (by default) at 3.141GH (3.142 if the rounding helps)

I wonder if there will ever be a Pi clocked (by default) at 3.141GH (3.142 if the rounding helps)

Ah – constant humour!