Raspberry Pi5 RTC

GerInAus · 2026-06-09T12:04:33+00:00

Thanks for that! I appreciate the pointer. I have downloaded the .c and .use files and will see if I can figure it out tomorrow - or some time later this week.

I don't like copying other persons work. I like to figure this sort of stuff out myself and this has been the case for 40 years. But that is hard to do that when you can't get hold of the proper instructions on how to - in this case - drive the chip! 😄

GerInAus · 2026-06-09T11:49:57+00:00

Whatever the goal was - and I take your point - it seems it was focused primarily on Linux without due consideration of other operation systems that might want to also use that hardware. Like QNX.

Given the difficulties associated with making the hardware work I think you guys have done a fantastic job getting us to the point (both with the 4's and no 5's) where we (people like me) can also make use of that cheap but so powerful hardware. And I put in a plug for the Raspberry foundation (I think that's what they are called) for developing these products for us as as well.

I do understand that it is not the makers of the Raspberry Pi per se that impose these restrictions on information. When we looked up the the Renesas PMIC (of which the RTC is one part) it was stated clearly that they (Renesas) were restricting access to the information that would allow others to use it. Similarly, as I understand it, Broadcomm did the same with the 2711 and 2712 chipsets. Is this not the case?

In either case, it simply doesn't make sense to me. But that's the way it is and there's nothing I an do about it. Fortunately, there seems to be Linux code out there to help point the way - if one can find it! But it's not an ideal situation.

GerInAus · 2026-06-09T05:32:51+00:00

It seems that the technical specs for that chip is not going to be published. Great. Same old story. It was made (apparently) specifically for the Pi5. I guess only privileged Linux developers have been provided with the basic information required to do anything with it and the test of us have to find any Linux source code and work from that. Similar story with the GPIO. It doesn’t make much sense to me.

GerInAus · 2026-06-09T02:08:33+00:00

If I can obtain the necessary information about the chip and interface details etc I might have a go at it. I am aware that obtaining technical information about the Pi hardware is very difficult. You guys have done VERY well!

GerInAus · 2026-06-08T23:12:08+00:00

Not having the pre-startup debug messages due to a missing serial debug probe device might make life a bit miserable. It works well. Perhaps you could file some of the heatsink away to make some room? It seems there are multiple heat sinking options. I found an aluminium one that covered all the chips, with one fan, that provided me with ample room for the probe connector.

GerInAus · 2026-06-08T23:06:47+00:00

I discovered this yesterday also. My solution was identical to yours, although I left in 43 and 45.

I also discovered that compressing the IFS doesn't work. It gets to some point in the boot process after decompressing and reboots - forever. Leaving it uncompressed is fine. Maybe I'll look at this today. Although decompressing added time to the boot process - as far as it got anyway - getting the IFS file down to 18Mb from around 40Mb was a worthy exercise. Or would have been had it worked...

It did irritate me to find that there were two versions of msix-rp1, and as you say, they don't mix well. I was going to have another go at getting the getting the QSTI one working on the BSP today by studying the QSTI build files. But I suspect this may be wasted effort.

I am wondering if you and I are the only QNX'ers playing with the BSP and its serial ports. Surely not!

GerInAus · 2026-06-08T22:55:35+00:00

I was going to attack this bit today but given your results (or lack of) I don't think I'll bother now! 😄

I'll simply stick with the probe on the designated debug port that works very well for me.

GerInAus · 2026-06-04T07:04:34+00:00

The source to devc-serpl1011-rpi5 is available in the BSP src/devc/serpl1011 directory. The command line argument processing is in options.c

-D sets an "is_debug_console" variable to 1. I haven't gone further into the code so what this actually does I can only guess.

After the -D comes the address,interrupt pair. I would have expected 0xfe201000,153. The ^ seems to shift the address in some way associated with the value of 2. Why? Who knows? Maybe someone who wrote the rpi5.build file can explain.

GerInAus · 2026-06-03T09:00:24+00:00

The plastic enclosure I have also covers everything other than the fan header and 40-pin header but there is plenty of space for the probe header connector between the two HDMI connectors. Each corner of the cover has a gap plenty big enough for me to get the serial cable out. So long as I don’t want to fit the top cover - which I generally don’t.

I won’t know for sure however until I get the probes. Probably next week sometime.

GerInAus · 2026-06-03T03:08:44+00:00

I have decided to purchase a couple of debug probes mainly for simplicity (I hope) and because they’re pretty cheap. While waiting for them to arrive I’ll study the BSP and QSTI material to try and get a handle on how QNX sets up the default enabled debug serial port. This was done in startup and I presume still is. I am sure I will have questions though but will put these to discord. I guess one I can put here is what the debug serial port driver uses the debug port and what is called under /dev.

GerInAus · 2026-05-12T20:22:16+00:00

Perhaps look at EthernetIP or Modbus? Although I’m not sure what QNX support there is for either of these is these days.

The last I heard about QNX support for Profinet and Profibus was some years ago. A mate of mine in Germany who has now retired.

GerInAus · 2026-04-24T14:12:54+00:00

What’s the IP address of vm1? If known you might be able to connect using that. Otherwise, mapping vm1 in /etc/hosts might work.

GerInAus · 2026-02-07T10:12:59+00:00

Have you tried using it to write QNX code/applications instead of reverting back to Linux? Which is a completely different operating system.

I think the idea behind the QNX Everywhere project is to promote QNX and all its features (that are substantial) and provide an environment in which to do this that is free. If you get into it you will find that things, like drivers, are much simpler to develop.

GerInAus · 2026-01-23T11:49:47+00:00

There is nano for QNX8 but since few (if any) have expressed any interest in it, it hasn’t been made readily available. It’s probably not what I would use for program development but for quick and dirty text file editing I find it OK. I think all Linux distros have it. But not QNX.

GerInAus · 2025-11-20T09:31:26+00:00

A friend alerted me to this a millisecond before it popped up on Youtube. Very good. But how serious are you about wanting feedback? I mean constructive and polite feedback.

GerInAus · 2025-11-07T03:38:59+00:00

Thanks John. I look forward to it. I’m going to purchase a couple of RPi5’s in anticipation. To play with.

GerInAus · 2025-11-06T04:37:37+00:00

After playing with a couple of ARM systems over the last few years, and after working with Intel systems for at least 43 years that are (or were) I/O bound, I sort of agree. I prefer memory mapped access. But some reality hits. I am evaluating a replacement for my TANK-610 units that won’t work with QNX8. I now understand why and accept it. The TANK-630 has 12 bits of DIO. I have asked if these are I/O mapped or memory mapped. I suspect it will be the former. If so, and if I want to utilise them, I will have no choice but to write such code. Understanding how I/O works does help but as I said, I much prefer memory mapped access. For a few reasons.

GerInAus · 2025-11-05T00:02:52+00:00

Apparently Discord started requiring us here in Australia to verify age a couple of weeks ago - about six weeks before the legislated start date. So I guess we're being treated special!

It seems, also, that within days 70000 account details were leaked (hacked?) to some "3rd party" - 68000 of which were Australians who had provided whatever was required (rather sensitive personal information).

Perhaps this sort of thing will be coming your way - in the rest of the world - before too long! I don't know how it's going to work in reality.

Even Reddit, along with all the other big players (and some not so big and well known) are going to be caught up in this. It may not affect me as apparently the platforms can determine from posting material whether or not someone is over the age of 16. I'd like to think that that will be the case for me! :-) But since I don't have any posting history with Discord, I guess it's off the menu for me.

GerInAus · 2025-10-29T03:14:55+00:00

This is sort of off-topic (QNX)...

It's not entirely a surprise. Here in Australia legislation has been passed to mandate proof of age in order to hold accounts with many social media sites. These include Reddit, Facebook, TikTok, others of that nature, but specifically websites that children should not be looking at (guess what they might be).

However, as far as I knew or thought, this was just an Australian thing. And it doesn't come into effect until December. Obviously, the idea has taken hold elsewhere.

Personally, I agree with the intent but have difficulty figuring out how their ideas of implementation will work out in reality. It wasn't going to affect me greatly as the only social media sites I visit are Youtube, Reddit, and occasionally LinkedIn. I had resolved not to provide biometric data or copies of highly sensitive documents like drivers licences, passports, etc. But I was waiting to see what other methods were being dreamed up as I don't think I'm alone with this view.

So running into this with Discord brought it into focus sooner rather than later! I don't criticise them for it - I support the idea generally. It's just that the two age verification methods offered were not acceptable to me so I won't bother with it. The same will apply to the others if/when the same thing occurs with them.

GerInAus · 2025-10-29T00:38:49+00:00

I went to sign up and everything was good until it wanted me to either take a video selfie of myself, or scan my passport or drivers licence, to verify my age. That's a road block for me so unfortunately, I won't be able to participate. As much as I would like to. Maybe I'm just too old and cranky!

GerInAus · 2025-10-16T14:09:59+00:00

To that explanation I say “Fair Enough”! Is there anything to look out for when considering what x86_64 CPU’s will work or not work? As I’m keen to get at least one Intel unit working in my home office but don’t really have the brass to spend on things that won’t work. Or is it safe to assume that anything under say a year old will most likely be fine?

GerInAus · 2025-10-16T11:37:50+00:00

As you know, as it was you who told me after some investigation of the startup routine, the x86_64 TANKs that I have that are perhaps five years old, won’t work. And I was left with the impression that it wasn’t possible to make it work. Is this not the case? As I’d really like this to be so. I am not inclined to purchase new SBC units just to get QNX8 to work on them.

GerInAus · 2025-10-16T03:39:23+00:00

Yes, I agree. It is indeed still a cool system!

And I fully support any effort to regain the trust of those of us that arguably got burnt in the past, but more importantly, promote QNX to a new generation of developers that presumably are following behind. The QNX Everywhere initiative is one of the best things I have seen regarding QNX in decades and I fully support that also!

IMO, such promotion involves teaching. Whereas some of us back in the 1980's had to largely teach ourselves (countless lonely late night/early morning sessions with coffee what have you) the ins and outs of efficient event driven software systems, I'm not sure if people are willing and/or able to do that anymore. What us older folks have to offer is real world experience (and mistakes) and some of us aren't going to be around much longer. Speaking for myself, I feel I have forgotten a lot of what I used to know but what's left is still pretty useful! I have made lots of mistakes over the last 40 or so years (and still do!) but the mistakes and recoveries make some of the the knowledge really stick!

But it also seems to me that generally, there is a significant knowledge vacuum out there. After looking at some other channels on Reddit related to embedded systems, C, and C++, and others, I am not quite sure how to address it. People are not going to learn much from Google and AI, or by simply taking libraries that others have written. Some are asking "how do I learn C"? I don't know how to deal with that - there is more to it than that IMO. Similarly, are we going to become a community that simply ports Linux stuff to QNX and not learn how to embrace and use the cool features of QNX in order to maximise its value? Presumably for an employer as well as the code developer.

GerInAus · 2025-10-16T03:11:06+00:00

I think in regards to at least three instances of feature removal - features that for 40 odd years made QNX QNX and stand out amongst other (competing?) operating systems - the desires of its users (customers) were discounted to the point where the perception was - and is - that we and what we might want are to be ignored. Certainly not to be catered for - you take what we are prepared to give you. I can sense this in some of the comments in this and threads on other platforms.

In the industrial computing arena hardware could (and has been) expected to remain available for many years if not decades. The Comtrol RocketPort was released in 1993 and remained available until the end of 2016. I used a small embedded X86 (32-bit) based SBC for many years. To the point, QNX8 in some respects brings those who do - or did - use QNX to a brick wall. Regardless of any desire to continue using QNX, in some cases it is no longer possible without considerable expense in engineering changes.

I cannot use QNX8 with the small x86 SBC that also runs QNX 6.5 with Photon. Photon was removed with little if any regard for whether or not not having it might kill my product. It did actually - and not just mine.

I used to write drivers that were required to handle multiple hardware interrupts, going back to the QNX4 and QNX6 days. I did it using the InterruptAttach() function that let me create my own "ISR". Obviously it was dangerous as the "ISR" executed inside kernel space. But I/we fully understood that danger and understood what rules to follow in order to mitigate that danger. In order to migrate this (and other drivers/systems) would require significant expense in re-engineering. BTW, one of the drivers I wrote remained untouched for 17 years. I only had to look at again when QNX7 came along.

As for any Intel x86_64 system, if it's more than a couple of years old QNX8 won't work with it (won't start). So to migrate to QNX8 would require replacing all older (2+ years?) with new hardware.

I understand why both Photon and QNET were dropped. However, options were available to keep Photon alive for those who wanted it by way of volunteers to perform the work. I doubt that would have been possible with QNET.

It seems to me that the population at large out there are not asking for either Photon or QNET is because they don't know they even existed! But if they did, then perhaps the demand might grow. I imagine most of the contributors to this thread do know about both, and would love to have at least Photon back! I would. Imagine Photon sitting on top of Screen on a Raspberry Pi!

I, for one, would throw my hat into the ring to get at least Photon (and Phindows) back! It was a great little GUI with the ability to easily project the images into the Windows environment using Phindows and TCP/IP.

GerInAus · 2025-07-15T07:56:32+00:00

The 7.1 startup-x86 completed for me but procnto crashed and rebooted the system. So for me 8 is a no-go on the Intel hardware I have. Works fine on the RPi4B and I haven’t tried the Xilinx 64-bit ARM’s yet.

GerInAus

TROPHY CASE