Jump to content


  • Posts

  • Joined

  • Last visited

 Content Type 


Member Map




Everything posted by KemoNine

  1. I ended up deploying monit to track and respond to the clock jump. I ended up telling monit to reboot the system whenever the clock jumps ahead too far to keep some of my services I have deployed happy. At the link below you'll find my monit config file for the time jump as well as a small python script that's run by monit to look for any time jumps over 3 months into the future. You can tune the python script to look for larger jumps as well as the monit config to restart ntp instead of performing a full reboot. https://paste.lollipopcloud.solutions/?4e7e74d941e2c77d#ck/F7Tv6UBadpzlU56v+vzalNf1646gM8iHLvA3wd7w= I hope this helps even if it's a rough work around.
  2. I'm also seeing this behavior on a sopine that I recently deployed. It's seemingly inconsistent as well. I checked the kernel config and it appears the CONFIG_FSL_ERRATUM_A008585 is enabled cat /boot/config-4.19.38-sunxi64 | grep -i CONFIG_FSL_ERRATUM_ CONFIG_FSL_ERRATUM_A008585=y And it's a very recent Arbian as well. 4.19.38-sunxi64 #5.83 Short of tracking the date every minute or so in something like Monit to fire off a reboot... does anyone know of a practical work around?
  3. I will dig around and see if I can work on enhancing the 4.x series drivers based on the data sheet as well as longsleeps existing driver. I only glanced over some of the code in the drivers. I understand. I wasn't trying to imply I expected help or a mentor. I was hoping others who know more about the kernel dtb stuff as well as driver dev could nudge me in a direction or two (as you did above). I understand the time scales and I apologize for using too strong of a word. That's a good approach. Would you recommend starting with the drivers and seeing what may or may not be implemented at the code level? Understood. If/when I get some extra cash I'll aim it your way. I appreciate the project and the amazing output.
  4. I've gotten that impression as I've dug into things on the Pine64[+] side. I'm a heavy Orange Pi user and the Pine64's power circuitry related to battery support is compelling for a current build of mine. I've been using Armbian base images for the last ~12 months for Orange Pi boards (of various forms) and finally hit a bit of a wall on my understanding thanks to the 4.x kernels missing dtb things for the Pine64[+]. The Pine64 series has been a thorn in my side since I started working with it. I've spent a lot of time digging into what's going on and it seems the dtb's are missing pieces/parts. However, the dtb parts of the kernel are new to me. I've not had to work with them in the past. I opened this thread in the hopes I could receive a bit of guidance and mentorship so I could conntribute patches and useful output to the Armbian project. I have kept an eye on that page on and off and that's part of why I opened this thread. I was hoping to get some help and/or mentorship on building out the dtb's for the Pine64 series of SBCs. The battery/charger side of the Pine64[+] setup seemed incomplete related to the power supply/battery dtb pieces in my research and that page doesn't mention the axp 803 chip in the pine64 as incomplete. I was hoping to get help sorting out what the heck I need to start probing the dtb's. This is new territory for me. I'm content to explode a board or two along the way but I need help figuring out where to begin and start the process of learning so I can submit patches/issues/etc in a useful way for the Armbian devs. That was my goal. My hope was to work with the Armbian devs/community to improve the dtb support for the /sys/class/power_supply side of the Pine64 series. I am unsure where to start. The best I can sort out presently is that the dtb setup for 3.10 and 4.x is very different and I'm not sure where to begin for sorting out differences. I'm content to throw myself at a wall to work through the problem and/or sacrifice a board or two to the cause. Unfortunately, I need help to figure out where to begin on reconciling the difference between the Pine64 3.10 dtb's and 4.x dtb's. I need help deciphering what the hell is going in on the 3.10.x "official" kernel and 4.x series so I can be of use. This is new territory for me. There is "throwing money at the problem" and "affordable". I have a feeling our definitions of both will be within a reasonable margin of error. As content as I may be to throw money at problems, my current cash flow situation doesn't cover the cost of what I'd consider reasonable for implementation, testing and release. As someone who has a $dayJob that's professional programming, I'm not inclined to belittle other programmers with paltry sums and big asks. That would be unreasonable and asinine. If it's OK, I'd prefer learning, donating my time and helping reduce the pain other programmers feel day to day. I'd appreciate NOT belittling you by undervaluing the worth of your precious time.
  5. I'm currently working with Armbian on a Pine64 and it looks like both the 4.14.x kernels and 4.19.x kernels are missing some dtb definitions related to the axp803 powersupply for /sys/class/power_supply to work properly. From what I can tell this thread: https://forum.pine64.org/archive/index.php?thread-1430-1.html Has a bunch of dtb related pieces missing from 4.x kernels Would someone be able to help me decipher the differences and put together a dtb overlay to hopefully sort this out? I'm willing to release the purple smoke (if things go awry) during testing to help get this sorted...
  • Create New...