Pull-ups on Raspberry Pi 3B+

I have loaded the module on my mini.m with just the checks for the Pi and version omitted. MCPIO_Info correctly reports the details of the mini.m, so my initialisation code should be ok as it stands. I am using RO 5.25 (03 Aug 2018). I certainly had the module in use at some RO shows in those early days.

Some progress: Steve Drain, thank you. I’ve used a modified version of your code on an old Pi, and I can set pull-up, set pull-down and clear pulls on GPIO17. So it proves that the hardware isn’t broken, and that Broadcom’s instructions work.

It doesn’t seem to work on Andrew Conroy’s 3B+. Investigations continue.

Steve: the physical address (&20200000) is OK for BCM2835 but not for BCM2837 – it needs to be &3F200000. Then we can set pull-ups on a 3B+ too.

I now have to work out how to tell the difference between the platforms.

CPUID?
https://www.riscosopen.org/forum/forums/11/topics/15091#posts-99569

Try to interpret the board ID?
https://www.riscosopen.org/forum/forums/9/topics/6347#posts-99206

So it proves that the hardware isn’t broken, and that Broadcom’s instructions work.

Well, I knew that!

for BCM2837 – it needs to be &3F200000

Thanks. The BCM2837 was not even a twinkle in Eben Upton eye when I wrote MCPIO. ;-)

What about the BCM2836?

I now have to work out how to tell the difference between the platforms.

That should be the job of OS_Hardware, so I must assume that is not working on the Pi you have tested, but it is working here and used to work in 2012.

This topic is possibly enough to get me to set up a Pi again and perhaps extend MCPIO to deal with the general case of Pi IO pins. ATM it is just for an 8-bit port.

I once had ambitions to explore the PCM possibilities.

Rick: in your second example, Tank’s code is exactly what Steve used to detect the platform. The call to XOS_Hardware returns R1 = -1 on both a Pi B rev 2 and a Pi 3B+. Not your code, I know.

We’re always told not to identify the platform, find the features and use those. But it doesn’t help in a relocatable module; in this case the features we’re looking at are identical, but the different processor chips put them at different addresses, so there has to be a way to find which address they’re at.

Not aimed at either Rick or Steve of course. I’m just musing.

In the end it’s not my problem (probably) – I’ve found the bug and reported it. I’m unable to fix the existing code because I don’t understand it.

I was just about to try Rick’s alternative code, but we’re going out for a walk right now.

Try !ScreenHelp version 1.64 from !Store – it identifies the platform, the revision number and the MAC address buts does have to resort (on the Pi) to sending mailbox messages. Then look for the bit you want, it’s all written in BASIC and assembler. It was written up in Archive 24:2.

The call to XOS_Hardware returns R1 = -1 on both a Pi B rev 2 and a Pi 3B+.

Yes. There used to be a HAL call that returned numerical values for device type and board type.
That call was quietly removed. Anything that used it, now probably fails.

We’re always told not to identify the platform,

Indeed. But sometimes, as this demonstrates, it is necessary to identify the platform. And people are going to devise all manner of hacky ways of doing exactly this since the OS is too bloody-minded to have a “what board is this” call.

Is “BCMSupport” available? Yup. Okay, then it’s a Pi. Is the processor ID saying it’s an ARM11? Okay, then the I/O base is here otherwise it’s over there…

but the different processor chips put them at different addresses,

I think it’s only the Pi1 that puts them low.

I was just about to try Rick’s alternative code,

How it works is that (newer?) versions of RISC OS provide a call that gives a text string that identifies the platform and board, it’s like the text that appears on boot. So my code does a very minimal attempt at parsing that text in order to see if it’s an original (or zero?) or anything else.
Honestly, you’d probably be better off just pulling the CPUID out and seeing if it’s the ARM11 version, as I believe the Pi1(/Zero?) is the only one that uses the twenty-twenty address.

You know…in the absence of the OS deigning to tell you either the hardware base address or the device type (as programmatically readable integer values such as those available by the code in ScreenHelp, as Chris suggests). :-)

But sometimes, as this demonstrates, it is necessary to identify the platform. And people are going to devise all manner of hacky ways of doing exactly this since the OS is too bloody-minded to have a “what board is this” call.

I don’t think the OS that’s being bloody minded about it! :)

No, but safer to blame an inanimate object that won’t get offended… ;-)

I think it’s only the Pi1 that puts them low.

If there is any difference like that between any platforms that code must run on, then the difference must be ascertained programmatically.

There used to be a HAL call that returned numerical values for device type and board type. That call was quietly removed. Anything that used it, now probably fails.

When the Pi first came along there was quite a push to get board info and cater for versions, with a bit of an interchange of information among a handful of programmers. GPIO and MCPIO do use a similar method for that reason, and it is true that there is an asumption about the version values. I am not surprised to find that it fails now.

The call to XOS_Hardware returns R1 = -1 on both a Pi B rev 2 and a Pi 3B+.

However, OS_Hardware is documented and the source Hdr seems to cater for the Pi as we would expect. The call works on my mini.m. for its GPIO, but fails for the Pi in a way the suggests there might, just possibly, be a bug ?!!!

But sometimes, as this demonstrates, it is necessary to identify the platform.

It is indeed.

if there is any difference like that between any platforms that code must run on, then the difference must be ascertained programmatically.

With many thanks to Chris and BCMSupport, it is now possible to do this for the versions of the Pi that this thread is concerned with. I will probably put this into MCPIO later today.

I will probably put this into MCPIO later today.

Well, I did that, but:

the physical address (&20200000) is OK for BCM2835 but not for BCM2837 – it needs to be &3F200000.

Does this apply only to BCM2837 or to BCM2836 as well?

I have decided for the moment to assume that only BCM2835 boards – 1A, 1B, 1A+, 1B+, CM1, Zero, ZeroW – have the lower address.

Apart from checking the details are correctly returned for a small selection of boards I have at hand, I have no way to check that the GPIOs are correctly set.

MCPIO is quite specialised for just one 8-bit port so it might not be all that useful. I realise that to extend it for Raspberry Pi IO generally would be treading on the GPIO module, though I may explore that for my own satisfaction.

I have decided for the moment to assume

Look at the HAL sources.

The header says:

IO_Base_BCM2835  * &20000000
IO_Base_BCM2836  * &3F000000 ; it moves in Pi 2
IO_Base_BCM2838  * &FE000000 ; and again in Pi 4
IO_Base2_BCM2838 * &FC000000 ; Pi 4 adds a second range of peripherals

The selection logic is here, about two thirds of the way down in HAL_Init (direct link, may not work on NetSurf; and the cpudetect macro is here).

Well, I’ve looked at the code. I find it utterly impenetrable.

[…]

I’m not trying to find some code that works; I don’t think I need any more help to understand the requirements that the document sets out. I want to understand why the existing code appears not to work. So I have to be able to follow the existing code.

I’m worried that you’re floundering on the rocks. You’ve done most of the hard work

• Realising that RISC OS 5 runs on top of a hardware abstraction layer
• Therefore the GPIO module doesn’t write to the hardware directly, that’s (probably¹) the wrong place to look
• The Pi HAL is where the action is

Specifically there’s a 31 line function which is (probably²) where to look. I’ve had a quick stare at it and it looks right, but desk space is short here and the Pi isn’t set up at present. It’s only 31 lines long, print it out, write notes explaining what it’s doing.

If messing in the HAL isn’t your cup of tea, copy the code into BASIC assembler and print out intermediate values (rather than accessing the hardware) and see if that gives any clues. Also, the *MemoryA command accesses IO in supervisor mode, so for little experiments just poke the registers and see what happens.

¹ Since it was mentioned to work right on OMAP3, I assume the GPIO module does call the HAL right

² There are 2 callers of the function, but they just shuffle registers around

(probably1) (probably2)

Is there a problem with superscripts?

My Chars gives me  ¹ and   ²   – is it just laziness?

Sprow: thanks for looking. Andrew Conroy and I have just been going through the code together (thanks to ChatCube!) and we think the problem is a bit higher up, in GPIOPullDirection. Look what happens at lines 662 to 665 if there never has been a pull set. AFAWCS a2 = a3 at line 665, so the function will always follow the EXIT EQ path.

Is there a problem with superscripts?

Not here, there isn’t. Maybe you need a better web browser which understands formatting?

Not here, there isn’t. Maybe you need a better web browser which understands formatting?

Can’t speak for anyone else but I plugged in my Pi Zero just so I could log into this forum and stay logged in long enough to make a comment. Most exclusive place on the Internet.

My Chars gives me ¹ and ² – is it just laziness?

^Picking _numbers ^out _of ^Chars _isn’t ^proper _superscript (^or _subscript). ^There _are ^markup _tags ^to _do ^it _properly.

Is anyone else looking at the code in question?

More eyes would be welcome.

The GPIO module is the same across all platforms, and it’s possible to manipulate pull-ups and pull-downs on other platforms, so it must be the HAL that’s causing the problem. This simplifies it to just one file.

https://gitlab.riscosopen.org/RiscOS/Sources/HAL/HAL_BCM2835/-/blob/master/s/GPIO looks to me to have one error. At line 804, the offset to the pull up/down clock enable register (could be one of two according to whether it’s GPIO 0..31 or 32 upwards) is computed in v4, but at line 842 v2 is used as the offset. So the clock enables are not being set correctly.

Four attempts to build the RasPi (unmodified code from a tarball of June 6) all fail at the stage of running egrep. Even running “egrep —help” in a task window does nothing, doesn’t come back, just consumes CPU clock cycles. Does anyone else have the same problem?

Edit: I had a years old version of !grep in Apps; it included a version of egrep. This was being used instead of the one provided in the source tarball. I think it must have predated the ARM version in the RPi 3B+. I’ve deleted it, rebooted, and now the ROM builds.

Is anyone else looking at the code in question?

Yes, but through a glass darkly. My lack of experience with the source is quite a barrier. ;-)

at line 842 v2 is used as the offset.

‘v2’ is copy of the ‘enables’, so that does look wrong and ‘v4’ should be used.

Something else looks odd with the use (not) of ‘sb’.

While perusing other documents I noted these points about the Pi4 GPIO:

*There is no BCM2838; it is BCM2711.
*There are 57 GPIO lnes rather than 54
*The lines are split into 3 banks not 2
*The distribution of lines differs from BCM2835
*PullUp/Down does not require the clock rigmarole
*PullUpDown state can be read

Am I correct?

I am adapting MCPIO, but that is relatively simple.

The error is the use of v2 instead of v4, as I showed above.

I raised bug 490; I’ve just updated it with details of the fix. I’ve tested the results on a 3B+ and a B rev 2. That’s all I can lay my hands on.

What happens now? Who’s going to review the fix and check it in?