Re: RPI4 + ntpdate + unbound
- Reply: Mark Millard : "Re: RPI4 + ntpdate + unbound"
- In reply to: John Kennedy : "Re: RPI4 + ntpdate + unbound"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 03 Jul 2022 18:22:29 UTC
> Am 03.07.2022 um 12:51 schrieb John Kennedy <warlock@phouka.net>: > > On Fri, Jul 01, 2022 at 10:49:33PM -1000, David Cornejo wrote: >> I always hated this about the RPIs - I put a DS3231 on mine and the >> problem disappears. ... > > Yeah. Not sure where Eben would cram it (much less the battery), but > one of these days his form factor needs to expand a bit. But with what > I do with the RPI4 it runs hot, so I've got a good passive case, but > this one hides the GPIO pins entirely and the active-cooling one I'm > looking at is a big chunk of aluminum + fans, which means some pretty > significant risers/headers to get it to clear the heatsink and some > contention with the PWR/GRD pins to power the fan. > > Haven't dug into what RTC driver FreeBSD may support to see where I > can stick the RTC. I do want one, just not seeing options that jump out > at me. Before this just ended weekend, I would have recommended the DS3231 as well, because it is working very well on my BeagleBone's Black for years now. It is very well documented and FreeBSD comes with a kernel module for it. Beginning on last Friday I started with FreeBSD 13.1-RELEASE on a brand new RPi 4 B 2 GB, and with that one, attaching the DS3231 became a major hassle. Here is the whole story: https://lists.freebsd.org/archives/freebsd-arm/2022-February/001024.html On 19.02.2022 6:01, Brian Scott wrote: > The MAX77620 driver introduced for an NVIDIA TEGRA210 system seems to > unilaterally claim anything at address 68. It doesn't understand the > DS3231 and fails to operate properly, but in claiming the device, the > ds3231 driver doesn't get a chance. This is compounded by the MAX77620 > driver being compiled into the kernel by default so the loadable module > doesn't get to try until after the wrong driver has claimed it. As suggested by Brian Scott, I compiled a custom kernel without the NVIDIA Tegra option. Only, with that custom kernel my RPi 4 (0xb03115) stuck at boot right before mounting the system partition. Then I switched to FreeBSD 14.0-CURRENT in which the problem has been resolved, and with that my RPi and the DS3231 is properly working. I got this one: https://produto.mercadolivre.com.br/MLB-971284468-ds3231-shield-relogio-tempo-real-arduino-rtc-eeprom-at24c32-_JM If you have a close look at the picture, you can see that I would have been able to change its address, by soldering the address pads A0, A1 and A2 respectively. Perhaps, I should have done this, since I would have liked to stay with RELEASE instead of CURRENT. The DTS code for the DS3231 is given in said thread on the mailing list. Using the dtc utility, I compiled a .dtbo and placed it into /boot/msdos/overlays as ds3231-rpi4.dtbo. Then I added two lines to /boot/msdos/config.txt: gpio=2,3=a0 dtoverlay=ds3231-rpi4 It is working now, but the operation felt like pulling teeth at the dentists. I am still surprised why we get the NVIDIA Tegra compiled in the kernel of a 13.1-RELEASE SD card image which according to its file name is destined to the Raspberry Pi's.