Ticket #503 (Open)Tue Dec 29 08:16:44 UTC 2020

This seems to work as far as I can see.
Picking GPIO18 from your example, that would be controlled by bits 24-26 of GPFSEL1, so I’ll use that as the bits are on a nice nybble boundary and easy to read by eye. GPFSEL1 is at &7E200004 which is &FE200004 in the ARM view.

Note: there’s a mistake in the ‘BCM2711 ARM Peripherals’ document from the Pi website which says the GPIO is at &7E215000, this is a copy/paste of the AUX registers from Chapter 2.

So do
*Memory P FE200004 +4
then
SYS"GPIO_WriteMode",18,5
then
*Memory P FE200004 +4
and the respective bits have changed to 5 (or whatever was given as R1 to the SWI).

On the Pi400 here, I get:
*basic
ARM BBC BASIC V © Acorn 1989

Starting with 651516 bytes free

>*Memory P FE200004 +4

Address : 7 6 5 4 B A 9 8 F E D C 3 2 1 0 7 6 5 4 B A 9 8 F E D C 3 2 1 0 : ASCII Data
00FE200004 : 00024000 : .@..
>SYS “GPIO_WriteMode”, 18, 2
>*Memory P FE200004 +4

Address : 7 6 5 4 B A 9 8 F E D C 3 2 1 0 7 6 5 4 B A 9 8 F E D C 3 2 1 0 : ASCII Data
00FE200004 : 02024000 : .@..

This appears, to my untrained eye, to show no change in the value. Is this correct? Was it a Pi4 or a Pi400 which you you tested it on and found the bits did change?

Note that I’m using the GPIO SWIs, not poking memory direct, so any typo in the BCM2711 document doesn’t affect code I’m typing.

I can get a change in value by doing this:
>SYS “GPIO_WriteOE”,18,0
>*memory P fe200004 +4

Address : 7 6 5 4 B A 9 8 F E D C 3 2 1 0 7 6 5 4 B A 9 8 F E D C 3 2 1 0 : ASCII Data
00FE200004 : 01024000 : .@..
>SYS “GPIO_WriteMode”, 18, 2
>*memory p fe200004 +4

Address : 7 6 5 4 B A 9 8 F E D C 3 2 1 0 7 6 5 4 B A 9 8 F E D C 3 2 1 0 : ASCII Data
00FE200004 : 02024000 : .@..

However it still doesn’t result in audio coming from GPIO18, which it does on earlier Pis and does on the Pi400 if I do this from RaspberryPi OS. Have you been able to verify that this does in fact chnage GPIO18 so that PWM audio is present on that pin?

In the first set of numbers (posted at 15:17:33) the SWI has had an effect: before the value was 00024000, and after 02024000.

> Was it a Pi4 or a Pi400 which you you tested it on and found the bits did change?
> Have you been able to verify that this does in fact chnage GPIO18 so that PWM audio is present on that pin?

Pi 400. It was a WiFi HAT which uses some of the SPI peripheral on some of the pins. The code must switch the port to SPI mode otherwise it doesn’t work, and that implies that the GPIO_WriteMode SWIs must be working.

So if the GPIO module is all working perfectly correctly then we’ve just kicked the can down the road. Do I need to open a fresh bug report that PWM audio is not being output via GPIO when requested, or can this ticket serve that purpose?

You can rename the title of a bug if you wish to (to keep the useful history together).
The assertion “Unable to change GPIO Mode on Pi4/400” doesn’t seem to hold water because

• The right bits changed to the right values in the registers after using the GPIO_WriteMode SWI
• That same SWI does allow the SPI bus to work

That’s not to say there’s something odd about PWM. eg. a default you were previously relying on is no longer that way, and Linux writes some register somewhere to rectify that, and RISC OS doesn’t.
Opening a ticket is no guarantee anyone will look at it, as evidenced by 13 year old tickets in the list here!

Ok, summary changed, lets see if someone else is willing to look into this bug.