[pine64: massive date/time clock problem]

4 hours ago, linda said:

Hi KemoNine,

unfortunately, the problem still occurs sporadically for me (kernel 4.17).

 

I have not found a solution and would also be very grateful for a practical work around.

[my current work-around: "systemctl restart ntp"]

 

 

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.

[pine64: massive date/time clock problem]

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?

[[Pine64] axp20 / sys/class/power_supply problems]

7 hours ago, Igor said:

It's not just that. DTB is hardware configuration but if the driver doesn't support functions, describing them doesn't bring functions up. This is probably the case here - I am not aware if anything has been moved further without investigation.

 

If you need to get an information from the chip and you are not willing to develop a driver further, you still can talk with AXP chip via I2C channels. It's a bit nasty, but it shall work. (use search for more info)

 

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.

 

 

7 hours ago, Igor said:

Ratio between people that know something and those who don't is extreme. Several (ten)thousands vs. 1? A lot of questions that newbies asks represent serious projects in value of tens of thousands of dollars. You can't ask amateurs to cover you that. I am making a virtual cue out of peoples wishes. Waiting time would be several years if you want expert attention on your problem ... if that one is working full time. I hope this give you some better scale?

 

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.

 

7 hours ago, Igor said:

I suggest people to start with a small things. Take some simple time consuming job away from "people that know something" and chances that AXP driver gets some attention will raise up. If many people will go that path, a lot more could be developed/solved. There are people who are working on the project but they are not hardcore developers. Not even close. But they are around every day and help on towards common goals.

 

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?

 

7 hours ago, Igor said:

On most optimistic estimation Armbian costs are covered up to 3-4% (Xunlong, FriendlyARM & Olimex) while end-users donations coverage is way below 1%.

 

Understood. If/when I get some extra cash I'll aim it your way. I appreciate the project and the amazing output.

[[Pine64] axp20 / sys/class/power_supply problems]

11 minutes ago, Igor said:

Modern kernel was written virtually from scratch.

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.

 

 

Quote

  Peek here http://linux-sunxi.org/Linux_mainlining_effort 

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.

 

Quote

do something https://www.armbian.com/get-involved

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.

 

Quote

cover some time https://www.armbian.com/donate.  

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.

[[Pine64] axp20 / sys/class/power_supply problems]

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...