Raspberry Pi SOC temperature Sensor
Chris Evans (457) 1614 posts |
Apparently there is a Temperature Sensor in the BCM2836 it is a “memory mapped GPU peripheral”. There is support in the latest Firmware/Debian Kernel. Sources to “/opt/vc/bin/vcgencmd measure_temp” which will read it, are due to be released by the Foundation soon. Anyone interested in writing a RISC OS driver? |
WPB (1391) 352 posts |
Is the mailbox protocol that talks to GPU registers implemented in the HAL as general purpose routines, or does bit of the HAL that needs it have its own code? Sorry, I haven’t been following R-Pi developments very closely to now. |
Theo Markettos (89) 919 posts |
The HAL uses the mailbox for initial setup, but it isn’t accessible for other programs. The BCMSupport module is supposed to provide this as a service for other modules – but there’s only a stub in CVS at the moment. John may have a later version he hasn’t checked in yet. |
Jeffrey Lee (213) 6046 posts |
That was the plan, yes. But we realised that once RISC OS is initialised the only thing that needs to make use of the mailboxes is the video driver. So to save time we skipped implementing BCMSupport and stuck some mailbox code straight into BCMVideo. Of course it’s possible John has a new version in the works, I’m not sure. |
Theo Markettos (89) 919 posts |
Ah. That’s rather awkward because my Linux bootloader does need to access it (reading the Linux kernel parameters, for example). So can I petition for it to be put into BCMSupport… at the very least, having something to arbitrate between different users is necessary. |
Jeffrey Lee (213) 6046 posts |
You can certainly petition for it, but I suspect it’s a bit too late to get it ready in time for the image launch. For arbitration the video driver just makes sure IRQs are disabled while the message box is in use. This is probably a terrible thing for our IRQ latency, but it’s likely to be your best option at the moment. |
WPB (1391) 352 posts |
Is there any news about BCMSupport? |
WPB (1391) 352 posts |
Is there any documentation for BCMSupport? I’d like to talk to the GPU to query the temperature. |
Jeffrey Lee (213) 6046 posts |
There’s no news or documentation. Volunteers who want to try implementing the module are welcome to give it a try! |
WPB (1391) 352 posts |
So does the HAL still talk directly to the GPU using the mailbox protocol with its own routines? And does that mean it would be unsafe to try to use the mailbox in other code? |
Dave Higton (1515) 3404 posts |
Not that I’ve looked at it, so I have no idea what I’m asking about, but… Would a BCMSupport module start by replicating the mailbox code from the video driver, and then adding more calls or addresses or whatever is required to access other functions? |
Jeffrey Lee (213) 6046 posts |
There are (IIRC) three bits of code which use the mailbox:
So if you were to try making some code of your own to use the mailbox you could run into issues with conflicts with BCMVideo.
That might work, although the code in BCMVideo is a bit messy. You’d probably be able to come up with something better by starting from scratch and using IRQs to drive most of the logic instead of the polling method that’s been used so far. But whatever approach you take, the module needs to be able to send messages in a non-blocking manner (not all messages require a response, and the GPU can be quite slow at responding, so it’s best to avoid blocking waiting for the message buffer to be returned whenever possible), should be re-entrant (e.g. BCMVideo currently buffers up palette updates and sends them in one big block on the next 100Hz tick – which could occur in the middle of a foreground operation which is sat waiting for a response to a message), and should ideally have its own internal buffers for storing messages (particularly because the caller won’t know if a non-blocking message has been consumed by the GPU yet) You’ll also probably want a low-level interface which allows raw single-word messages to be written to the mailbox directly (unlike the pointers to tag lists which is what’s commonly used). E.g. it’s a single-word message which is used to enable VCHIQ. |
WPB (1391) 352 posts |
Does BCMVideo just sit in an interrupt-enabled loop waiting for the GPU response, then? A quick look at MBWait in the sources suggests that it does, but I might have been reading it wrong.
Does the GPU raise an interrupt when a new response is delivered into the mailbox, then? |
Jeffrey Lee (213) 6046 posts |
Yes. But since there are only a couple of instances where it needs a response it usually just uses the fire-and-forget approach. Full details (or at least as much as I can remember):
Yes – or at least that’s what the HAL headers suggest. I haven’t checked the TRM to see how well the feature is documented! |
WPB (1391) 352 posts |
Great detail as usual, Jeffrey – many thanks. Is there a safe way to experiment with the mailbox even while BCMVideo is active? If I were at the CLI, not doing any mode changes or palette work, could I be sure that it won’t be accessing the mailbox, or does it do things say on the vsync ticker? |
Jeffrey Lee (213) 6046 posts |
Possibly. If you’re in a true colour mode then that should make sure there aren’t any palette updates coming through (e.g. flashing colours from the OS). You’d also have to make sure you’re in a mode with only one screen bank (I think the standard 1080p will do?) so that screen scrolling won’t cause any messages to be sent. And make sure the screensaver is disabled because blanking the screen sends a message too.
Actually this will cause problems – MBClaim will only reserve the stack buffer for the response if a response is requested for that instance. So for the situation where it’s confused, SendMBMessage calling MBWait will try copying the response into a buffer which hasn’t been allocated and corrupt the stack. (Data being sent is copied straight into the circular buffer, it’s only the response which gets placed on the stack) |
WPB (1391) 352 posts |
Thanks again. Presumably, of the three places where the MB is currently used, the HAL and VCHIQ can still continue to use their own code, in the knowledge that no other MB clients are up and running at the point when they need access to the MB. But BCMVideo would have to be modified to call the new MB module so that it shares the MB with other clients? Would an SWI interface suffice for this, or would the SWI calling overhead be a problem with BCMVideo? |
Jeffrey Lee (213) 6046 posts |
I implemented the BCMSupport module a few months ago, so there’s now a proper API for using the GPU mailboxes. Documentation is on the wiki: https://www.riscosopen.org/wiki/documentation/show/BCMSupport |
Theo Markettos (89) 919 posts |
Thanks Jeffrey. That was on my todo list for years but never got high enough up the priority queue to get scheduled. |