It seems I thankfully was wrong . From https://www.raspberrypi.com/news/int...aspberry-pi-5/
So there should be a Mesa Driver from the get-go.

2 members found this post helpful.

I'll initially set it like a PC, but not stress the graphics other than see how it plays a you-tube video and such. I have a 2TB Samsung T7 on the way as its 'OS drive'. And rather than use Slack, I'll just use PI OS as is. So basically kick its wheels and see what we have here ... then think of a good use for these new machines once I know what it can do. With 'only' 8GB and 4 cores, I don't expect it to be a real powerhouse with multiple VMs running and fast FreeCad, Kicad type work. Again, I have a workstation for those loads, so the RPI-5 won't be a disappointment in that area. That said, with 8GB it truly swimming in memory for my 'normal' usage of RPIs. Should be fun just to play around with, just like the others when they were released! Looking forward to it. Like potato chips, one is never enough .

1 members found this post helpful.

HAHAHA! I know exactly what you mean.

These SBC arm devices are a little addictive. With Slackware installed, even more so!

1 members found this post helpful.

If the RPi5's internal RTC is a crap thing, can we still use a external module? And disabling the internal one?

1 members found this post helpful.

I'm rather hoping...

... will tell me which driver the RPi5 onboard RTC is using.

seems like gpio is a work around, not sure if disabling onboard is necessary, Exaga do you know?

1 members found this post helpful.

No. In a word. I've scoured the Internet digging for info but cannot find any solid nitty-gritty details about the RPi5 RTC at this time.

It depends which interface the RTC is using, and I'm hoping it's I2C like many of my existing RTCs. In any event there should be a config.txt entry that disables it, the same as with wireless and Bluetooth. My best guess right now is to rmmod the appropriate module and forget about the onboard RTC, and if not then work it so that the correct /dev/rtcX is being used if there's more than the onboard one installed. Whatever needs to be done can be done, I'm quite sure. It may take a little tinkering to make happen but Slackware is always very accommodating with such things.

Seems like a dumb question, but can't any rtc just be adjusted into place by ntp? I do also feel the inaccuracies you mention for a 32.768KHz crystal are absolute 'worst case' scenarios.

Not sure what you're asking with any RTC being adjusted into place by ntp. It really depends on how a system is setup and configured. In a perfect world, and without any human intervention, at boot the system gets its time from the RTC if one is available, or by jiggery-pokery with the saved system clock when one isn't. Or not at all in some cases. If rc.ntpd is running on the system it will sync with another ntp server to update itself, and the kernel should then set the hwclock [RTC] from the system clock at some point. All this, of course, can be set up, invoked, done automagically and/or manually at any time.

When manually (re)setting the time on a Slackware system I'll do something like this, as 'root' user:
Which grabs the time from a ntp server [time.google.com] && then writes the system time to the hwclock [RTC], so they're both in sync. I have a script in /etc/cron.daily performing this task so that my system time and real time clock do not drift. I also have the same code running in rc.local and rc.shutdown to cover all eventualities.

The guestimated "±5 seconds per day and ±30 minutes per year" accuracy is self explanatory. This is the calculated time that may be gained or lost over an established duration and these are the metrics that have been published by the manufacturers. Given that crystal oscillators can be very inaccurate, one should expect the worst and view it as a bonus if/when that's not the case. I've tried, trialed, and tested dozens of RTCs over the years and I have yet to find a more accurate RTC than the ChronoDot v2.1 on the I2C interface, and the SparkFun DeadOn DS3234 on the SPI interface. Both these RTCs [using Maxim controllers] will not lose or gain more than 4-5 seconds per year, that's with temperature varients affecting things.

I'm not even interested in the ChronoDot v3 - it's the same MAX31328 controller (only on a smaller chip die) as the v2.1, the registers are identical in address and function and the accuracy spec's are identical too. They both boast 2ppm accuracy for operating temperatures in the 0'C to +40'C range, and 4ppm accuracy for operating temperatures in the -40'C to +85'C range. The ChronoDot v3 just has a really stupid and thoughtless design.

Thank you for that, Exaga. You explain it far better than I.

1 members found this post helpful.

Didn't noticed that RPi5 is now supported by SARPi! Thanks to Exaga

Not supported (yet) because the Raspberry Pi 5 hasn't been delivered and I have no way of testing anything. An installer and supporting pkgs have been built on a Raspberry Pi 4 running Slackware AArch64 current using a "best guess + shot in the dark + the blind leading the blind" methodology - that I've employed with some progressive success over the years. Time will tell if my jiggery-pokery will cut it this time around.

What I've built and made available so far is entirely experimental and may even kernel panic while trying to boot. Without a RPi5 to test on I thought it might be cool and funny to just upload it for public testing while I'm twiddling my thumbs waiting for it to arrive. Not anytime soon either, I highly suspect.

I grabbed the RPi OS blob (2023-10-10) the other day mainly to compare the 'inxi-G' output. But I've noticed they have a second build of 6.1.0 for the BCM2712, which is the RPi 5 SoC. It seems like the kernel stuff is out there, although the video stuff is still proprietary.

I'm working with stable_20231024 branch right now. I figured that a stable release the day after the RPi5 was made public is the one to use. I pretty much keep up with the more recent branches on the Raspberry Pi GitHub repository.