lanefu Posted February 17, 2020 Posted February 17, 2020 1 hour ago, denix said: Are there some new information's? We use more than 1500 pcs of orange pc plus. There are similar problems with freeze and date change. Main difference is that changed date is 1979. I'm just curious.. what do you use 1500 orange pc plus for? 1
denix Posted February 17, 2020 Posted February 17, 2020 3 hours ago, lanefu said: I'm just curious.. what do you use 1500 orange pc plus for? Some bill printer device 2
Jasontan Posted March 3, 2020 Posted March 3, 2020 On 2/18/2020 at 4:00 AM, denix said: Some bill printer device Hi Denix, with regards to the "some bill printer device" you mentioned, are you referring to using device to control the receipt printer to print out receipt? Or to make use of the device to intercept the receipt? We're currently looking for this kind of solution, if you don't mind, may we get in touch with you?
denix Posted March 8, 2020 Posted March 8, 2020 On 3/3/2020 at 3:20 AM, Jasontan said: Hi Denix, with regards to the "some bill printer device" you mentioned, are you referring to using device to control the receipt printer to print out receipt? Or to make use of the device to intercept the receipt? We're currently looking for this kind of solution, if you don't mind, may we get in touch with you? Reply in private message
Splitice Posted March 10, 2020 Posted March 10, 2020 This remains a pretty serious issue. Has anyone made any pertinent discoveries? So far I've identified that boot time is unaffected, clock monotonic is getting incremented to the point of causing an overflow of the 32bit time number (hence 197x). Currently suspecting timer inaccuracy during frequency changes or something similar. Although not able to replicate in a lab at all (only in field).
Werner Posted March 10, 2020 Posted March 10, 2020 Not sure if this is the same issue but there was recently a discussion about time travel on H3 in #linux-sunxi and megi posted a patch for 5.6 at least. https://megous.com/git/linux/commit/?h=orange-pi-5.6&id=de12213dc2824b7eea293403b368ca75637016df
Splitice Posted March 10, 2020 Posted March 10, 2020 It's about this issue for sure. I'm yet confirm fix one way or the other yet though. Working on it. 1
Pol Isidor Posted March 10, 2020 Posted March 10, 2020 For system crash fixing the xpu on one frequency id definitely the soultion. I had even 50+ days online. Without, maximum in 2 days i had frezze and not accessible ssh.Sent from my MI 6 using Tapatalk
Sean Fei Posted May 3, 2020 Posted May 3, 2020 I have the same problem. I use approx 200. pcs of orange pi zero. use the board to monitor our remote devices, but after the time changed to 1979, the pi stopped working, ssh not working, scheduled reboot in crontab not working., not getting dhcp IP address from the router. basiclly just dead. Then I need drive 50 - 200 Km to fix the issue, really pain in the ass. Raspberry Pi is good, never fail, but use too much power for Solar powered system. I tried some different version of armbian, found Buster has more change get the problem than Bionic. I currently using Bionic mainline based kernel 5.4.y for Nanopi Neo/Core on my Orange Pi zero Lts. I have 15 Pis with this version, no one has failed(40+ days). Waiting on someone find out root cause and a permant solution.
Werner Posted May 4, 2020 Posted May 4, 2020 4 hours ago, Sean Fei said: Raspberry Pi is good, never fail You get what you pay for I guess... Quote tried some different version of armbian All flavors (Focal, Bionic, Buster...) sharing the very same kernel package. Did not follow up, maybe @Splitice can tell us about the mentioned patch if it worked and has been pushed to mainline.
Splitice Posted May 4, 2020 Posted May 4, 2020 These are the 2 patches we ended up with. With thanks to everyone at on the linux-sunxi irc, particularly megi. diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c index 6b636362379e..ca55c2ae999d 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c @@ -23,15 +23,21 @@ #include "ccu-sun8i-h3.h" -static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux", - "osc24M", 0x000, - 8, 5, /* N */ - 4, 2, /* K */ - 0, 2, /* M */ - 16, 2, /* P */ - BIT(31), /* gate */ - BIT(28), /* lock */ - CLK_SET_RATE_UNGATE); +static struct ccu_nkmp pll_cpux_clk = { + .enable = BIT(31), + .lock = BIT(28), + .n = _SUNXI_CCU_MULT(8, 5), + .k = _SUNXI_CCU_MULT(4, 2), + .m = _SUNXI_CCU_DIV_MAX(0, 2, 1), + .p = _SUNXI_CCU_DIV_MAX(16, 2, 1), + .common = { + .reg = 0x000, + .hw.init = CLK_HW_INIT("pll-cpux", + "osc24M", + &ccu_nkmp_ops, + CLK_SET_RATE_UNGATE), + }, +}; /* * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c index 5e7e9cccc172..609e889cae3c 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c @@ -1129,20 +1129,6 @@ static const struct sunxi_ccu_desc sun50i_h5_ccu_desc = { .num_resets = ARRAY_SIZE(sun50i_h5_ccu_resets), }; -static struct ccu_pll_nb sun8i_h3_pll_cpu_nb = { - .common = &pll_cpux_clk.common, - /* copy from pll_cpux_clk */ - .enable = BIT(31), - .lock = BIT(28), -}; - -static struct ccu_mux_nb sun8i_h3_cpu_nb = { - .common = &cpux_clk.common, - .cm = &cpux_clk.mux, - .delay_us = 1, /* > 8 clock cycles at 24 MHz */ - .bypass_index = 1, /* index of 24 MHz oscillator */ -}; - static void __init sunxi_h3_h5_ccu_init(struct device_node *node, const struct sunxi_ccu_desc *desc) { @@ -1161,13 +1147,6 @@ static void __init sunxi_h3_h5_ccu_init(struct device_node *node, writel(val | (0 << 16), reg + SUN8I_H3_PLL_AUDIO_REG); sunxi_ccu_probe(node, reg, desc); - - /* Gate then ungate PLL CPU after any rate changes */ - ccu_pll_notifier_register(&sun8i_h3_pll_cpu_nb); - - /* Reparent CPU during PLL CPU rate changes */ - ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk, - &sun8i_h3_cpu_nb); } static void __init sun8i_h3_ccu_setup(struct device_node *node) You may also need to decrease the DDR frequency by 24Mhz in uboot on some boards. No binning on H3 chips, some are inferior. This is not mainlined. Nor am I aware of any effort being put into pushing them upstream. No rights reserved by me. As always apply at your own risk, neither me or my employers provide you with any guarantees. 1
StefanH. Posted May 4, 2020 Posted May 4, 2020 On 9/27/2019 at 9:39 AM, StefanH. said: wow, I wasn't notified about all the replies here since I posted in May 2019. Unfortunately the problem has now occured 3 times since April. I have gone through all the dist-upgrades but the issue still persists. This is soooo annoying as I run my home automation system on the Orange Pi. The WAF is going dramatically down :-( Will try the CPU speed setting as well, but usually it takes a few months for the issue to re-appear on my side After I set the CPU speed as described above the issue never came back 1
Mikhail Kulinich Posted September 11, 2020 Posted September 11, 2020 On 5/4/2020 at 9:04 AM, Splitice said: These are the 2 patches we ended up with. With thanks to everyone at on the linux-sunxi irc, particularly megi. diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c index 6b636362379e..ca55c2ae999d 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c @@ -23,15 +23,21 @@ #include "ccu-sun8i-h3.h" -static SUNXI_CCU_NKMP_WITH_GATE_LOCK(pll_cpux_clk, "pll-cpux", - "osc24M", 0x000, - 8, 5, /* N */ - 4, 2, /* K */ - 0, 2, /* M */ - 16, 2, /* P */ - BIT(31), /* gate */ - BIT(28), /* lock */ - CLK_SET_RATE_UNGATE); +static struct ccu_nkmp pll_cpux_clk = { + .enable = BIT(31), + .lock = BIT(28), + .n = _SUNXI_CCU_MULT(8, 5), + .k = _SUNXI_CCU_MULT(4, 2), + .m = _SUNXI_CCU_DIV_MAX(0, 2, 1), + .p = _SUNXI_CCU_DIV_MAX(16, 2, 1), + .common = { + .reg = 0x000, + .hw.init = CLK_HW_INIT("pll-cpux", + "osc24M", + &ccu_nkmp_ops, + CLK_SET_RATE_UNGATE), + }, +}; /* * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c index 5e7e9cccc172..609e889cae3c 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c @@ -1129,20 +1129,6 @@ static const struct sunxi_ccu_desc sun50i_h5_ccu_desc = { .num_resets = ARRAY_SIZE(sun50i_h5_ccu_resets), }; -static struct ccu_pll_nb sun8i_h3_pll_cpu_nb = { - .common = &pll_cpux_clk.common, - /* copy from pll_cpux_clk */ - .enable = BIT(31), - .lock = BIT(28), -}; - -static struct ccu_mux_nb sun8i_h3_cpu_nb = { - .common = &cpux_clk.common, - .cm = &cpux_clk.mux, - .delay_us = 1, /* > 8 clock cycles at 24 MHz */ - .bypass_index = 1, /* index of 24 MHz oscillator */ -}; - static void __init sunxi_h3_h5_ccu_init(struct device_node *node, const struct sunxi_ccu_desc *desc) { @@ -1161,13 +1147,6 @@ static void __init sunxi_h3_h5_ccu_init(struct device_node *node, writel(val | (0 << 16), reg + SUN8I_H3_PLL_AUDIO_REG); sunxi_ccu_probe(node, reg, desc); - - /* Gate then ungate PLL CPU after any rate changes */ - ccu_pll_notifier_register(&sun8i_h3_pll_cpu_nb); - - /* Reparent CPU during PLL CPU rate changes */ - ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk, - &sun8i_h3_cpu_nb); } static void __init sun8i_h3_ccu_setup(struct device_node *node) You may also need to decrease the DDR frequency by 24Mhz in uboot on some boards. No binning on H3 chips, some are inferior. This is not mainlined. Nor am I aware of any effort being put into pushing them upstream. No rights reserved by me. As always apply at your own risk, neither me or my employers provide you with any guarantees. Was this patch ever added to upstream? Experiencing the same issue with couple of OrangePI One boards.
Werner Posted September 11, 2020 Posted September 11, 2020 18 minutes ago, Mikhail Kulinich said: Was this patch ever added to upstream? Try to check here: https://github.com/megous/linux/tree/orange-pi-5.9
Mikhail Kulinich Posted September 11, 2020 Posted September 11, 2020 40 minutes ago, Werner said: Try to check here: https://github.com/megous/linux/tree/orange-pi-5.9 Nice! Thanks! This patch was pushed yesterday to orange-pi-5.9 branch, 2 commits below : https://github.com/megous/linux/commit/417a54f606c4ccf75023da0d165febe1a30e2764#diff-874a1d4d688766992a150cf3b81a4d8c https://github.com/megous/linux/commit/a42d5d4f49814e98cc7420d433d2a2f1c2ce8996#diff-874a1d4d688766992a150cf3b81a4d8c orange-pi-5.8 branch has those patches as well: https://github.com/megous/linux/commit/1808a619f48d2380d528d3f3d3778c48edba6116#diff-874a1d4d688766992a150cf3b81a4d8c https://github.com/megous/linux/commit/5566c7d7c9288d62792d6f9075e3dde3278811f8#diff-874a1d4d688766992a150cf3b81a4d8c
Mikhail Kulinich Posted September 11, 2020 Posted September 11, 2020 Just curious, if I build an image based on 5.8 or 5.9 branches, it will contain those fixes, right?
Werner Posted September 12, 2020 Posted September 12, 2020 12 hours ago, Mikhail Kulinich said: Just curious, if I build an image based on 5.8 or 5.9 branches, it will contain those fixes, right? Correct. Armbian is using these very same branches to build image for sunxi and sunxi64 families with some extra patches on top. 5.8 is current and 5.9 is dev atm.
nPHYN1T3 Posted March 19, 2021 Posted March 19, 2021 It's 2021 and this issue still persists on ARMBIAN 5.83 stable Ubuntu 18.04.5 LTS 4.19.38-sunxi. My time is always Apr 1st 1980 (like it's a joke). fake-hwclock release date is in the future: 2016-04-15 00:00:00 Current system time: 1980-04-01 10:17:02
Werner Posted March 19, 2021 Posted March 19, 2021 1 hour ago, nPHYN1T3 said: 5.83 You are using outdated software and complain it has bugs?
nPHYN1T3 Posted March 19, 2021 Posted March 19, 2021 LTS release is not "outdated" and it's something that has persisted through a few releases. Perhaps if you are time traveling and commenting from the year 2023 then perhaps you can say 18.XX LTS is "outdated" but for now it is not.
Recommended Posts