spqr

One more question for you... with the kernel "thinking" it's running at 1GHz (even though it isn't) that means it is still using the AVS logic as if it is running at 1GHz, correct? Aren't all the problems I'm seeing telling us that the hardware even has stability problems at 800 MHz? So the kernel patch I showed above wasn't sufficient. I wonder if Marvell is doing anything about this. The espressobin has such great potential... there are a few commercial products built around it already. I don't understand how they could be ignoring these stability issues.

Thanks! I tried the patch of MIN_VOLT_MV overnight and it didn't address the spontaneous rebboting that I'm seeing on one of my v7 boards. Thanks to your description above I see that setting MV to 1108 is effectively the same as disabling AVS anyway. :-) The beauty of the convoluted code was that I couldn't tell what the unchanged levels were. ;-) Sadly, I have another unstable v7 board on my hands. :-( UPDATE... actually it looks like when I went to install the updated kernel deb that the process was interrupted by... a spontaneous reboot. So, it actaully hadn't installed my new kernel with the voltage patched. I have it installed now running. We will see if this fixes the reboot problem. UPDATE-2... up over 5 hours with the MV patch, stay tuned. UPDATE-3... no go, rebooted after 8:49 :-( This appears to have nothing to do with the voltage. I really don't get it because this unit stayed running for weeks when I first got it. Meanwhile my v5 unit with the same build of Armbian has been up 26 days.

I'm fuzzy on it myself. I always thought my boards were running at 1GHz until FlashBurn explained otherwise. I hope he will chime in soon on this point.

Only side effect would be slightly increased power consumption at idle, for other clock frequencies. I don't have a sense for how many non 1GHz espressobins are out in the world. As it stands many v7 boards kernel panic, freeze or reboot with all kernels missing the equivalent of this patch. I have v5 and v7 and all are 1GHz (though if you read above, apparently it really is 800 MHz internally and I'm waiting for FlashBurn to confirm the cpufreq code executed the 1000 MHz code path.

It seems that in the current code, the simplest patch would be to simply change the value of MIN_VOLT_MV to 1108. Is that too "brute force?"

I found the avs tables etc. over in armada-37xx-cpufreq.c where you mentioned. If I understand the patch correctly, it just sets level 1-3 to 1108 while leaving level 4 whatever it was. (basically making 1108 the lowest voltage ever goes for freq 1000MHz) I wonder if Marvel has anything in the chip errata about this or if they will be fixing it? How does this fit in with the 1000MHz is really 800MHz that you explained to me above? Is the code actually executing the voltage selection for 1000MHz even though the chip is really running at 800?

I was just hunting around and could find no *regulator.c file for Marvell and was wondering what happened. :-) I've been running armbian on one of the three "stable" v7 devices I had and it is no longer "stable." I'm not getting kernel panics, but it sporadically reboots... I suspect it may be this same cause. My application for the espressobin really requires long term stable operation, so I hope we can get to the bottom of this. Can you post where you apply this patch so I can also test it with you?

There is a patch for AVS on the espressobin site. I'm not sure if this was somehow missed in the ubuntu and other builds. this patch was specific for v7 of the board. found here: http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Kernel#Kernel_version_4.14 in the zip file... I'm going to build/test in Armbian. From 0bb9aab4c7706139a8d18f67a07c462fcfcf7327 Mon Sep 17 00:00:00 2001 From: Victor Gu <xigu@marvell.com> Date: Wed, 20 Sep 2017 10:00:49 +0800 Subject: [PATCH 3/8] fix: regulator: armada-37xx: overwrite CPU voltage values in 1000MHZ The original CPU voltage values from load 1 to load 3 are too low for EspressoBin board with Armada-37xx SoC when CPU is 1000MHZ, which leads to instability that CPU gets stuck soon during dynamic voltage scaling. In order to fix this issue, this patch adds the compatible string for EspressoBin AVS, and update the CPU voltage values from load 1 to load 3 in 1000MHZ mode accordingly, the value is updated from original 1.05v to 1.108v. Change-Id: Iae22cb3bb243b3345e7426e859313139637f09e7 Signed-off-by: Victor Gu <xigu@marvell.com> --- .../devicetree/bindings/regulator/armada3700-regulator.txt | 2 +- drivers/regulator/armada-37xx-regulator.c | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/regulator/armada3700-regulator.txt b/Documentation/devicetree/bindings/regulator/armada3700-regulator.txt index 7ed7a61..5a853dd 100644 --- a/Documentation/devicetree/bindings/regulator/armada3700-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/armada3700-regulator.txt @@ -1,7 +1,7 @@ Marvell Armada 3700 voltage regulator by AVS Required properties: -- compatible: must be "marvell,armada-3700-avs" +- compatible: must be "marvell,armada-3700-avs" or "marvell,armada-3700-espressobin-avs" - reg: avs register address, which is used to control CPU voltage - clocks: CPU core clock to get the MAX CPU frequency - any required generic properties defined in regulator.txt diff --git a/drivers/regulator/armada-37xx-regulator.c b/drivers/regulator/armada-37xx-regulator.c index bd3b950..1185f6a 100644 --- a/drivers/regulator/armada-37xx-regulator.c +++ b/drivers/regulator/armada-37xx-regulator.c @@ -274,6 +274,7 @@ static int armada_3700_avs_probe(struct platform_device *pdev) struct regulator_config config = { }; struct regulator_dev *rdev; u32 max_cpu_freq; + int idx; avs = devm_kzalloc(&pdev->dev, sizeof(*avs), GFP_KERNEL); if (!avs) { @@ -315,6 +316,13 @@ static int armada_3700_avs_probe(struct platform_device *pdev) avs->freq_level = CPU_FREQ_LEVEL_800MHZ; } else if (max_cpu_freq == CPU_FREQ_1000MHZ) { avs->freq_level = CPU_FREQ_LEVEL_1000MHZ; + /* + * Overwrite the VDD values from load 1 to load 3 in 1000MHZ + * for EspressoBin, otherwize the CPU gets stuck. + */ + if (of_device_is_compatible(np, "marvell,armada-3700-espressobin-avs")) + for (idx = VDD_SET1; idx <= VDD_SET3; idx++) + voltage_m_tbl[avs->freq_level][idx] = 1108; } else if (max_cpu_freq == CPU_FREQ_1200MHZ) { avs->freq_level = CPU_FREQ_LEVEL_1200MHZ; } else { @@ -399,6 +407,7 @@ static const struct dev_pm_ops armada_3700_avs_pm_ops = { static const struct of_device_id armada3700_avs_of_match[] = { { .compatible = "marvell,armada-3700-avs", }, + { .compatible = "marvell,armada-3700-espressobin-avs", }, {} }; -- 1.9.1

Hi, I bought the edimax EW-7822ULC usb wifi device (based on rtl8822). I was able to build the driver, install it, and test it (works!). Edimax provides the sources on their site. Is anyone working on incorporating this into Armbian? Steve

Interesting. Is the kernel developer connected with Globalscale or Marvell? I returned my batch of failing units to Globalscale and they have reproduced and are looking into the problem. It could be completely unrelated as well... but maybe not.

Just my 2-cents on the ethernet port ordering issue... Even though boards prior to v7 had the port naming flipped, it seems more "industry standard" to have the wan port on the left. Now that globalscale is shipping cases and the metal version has WAN screen printed on the left one (which is also separated off from the other two) would it really offend any v5 users if the order changes? I think it would be good to just commit that change unless some v5 users really feel strongly about it...

Confirmed... 800 on both v5 and v7 :-( Thanks

Um... wait, really I'm not running at 1GHz? This is my v5. root@espressobin:/var/log# tail armbian-hardware-monitor.log name: SS08G ### Boot system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU 20:11:06: 1000MHz 1.18 78% 37% 38% 0% 2% 0% -75000°C 20:11:07: 1000MHz 1.16 60% 7% 50% 1% 1% 0% -75000°C 20:11:07: 1000MHz 1.16 60% 7% 50% 3% 0% 0% -75000°C 20:11:07: 1000MHz 1.16 67% 9% 56% 1% 0% 0% -75000°C 20:11:08: 1000MHz 1.16 93% 12% 79% 2% 0% 0% -75000°C

Sorry, I didn't know this. I assumed that because I used the u-boot 1000-800 (ddr3 1 GB RAM 2 chip) for the v5 I was running at 1GHz. I'm really only messing with the v5 as a "lab experiment" because I've been ordering v7 for my application. (FYI The v5 I have has no been up well over 24 hours on the kernel I built with no panics or freezes.) Stability on v7 has been fairly elusive and I don't know if that was just bad luck or some actual hardware issue that isn't being properly handled. I'm awaiting answers from Globalscale but continuing to make (software) progress on my project with the v5 and three working v7 units I have.

I built kernel v4.19.20 as described above and it seems to be running stably on my (previously known stable) v5 and v7 hardware at 1GHz. The only change to "patches" that I made was the switch of wan and lan1 (which, I think, had been backed out of next). The v7 (my main focus) has been up over 48 hours the v5 less than 12 hours, but I'm leaving it running and will update tomorrow.

Built! Installed! Port order flipped! That was easy! I'm leaving it running to make sure I don't see any freezes or kernel panics.

Thank you! now we both know. I've already kicked off the build!

Thanks... brute-force, but workable. ;-) I was so sure there was some way to feed a version in...

I want to build the specific kernel version 4.19.20 ... but when I do the armbian build of "next" it builds 4.19.27 I don't see anywhere in the build tool doc's where it tells me how I can do that. My primary purpose is to flip WAN and LAN1 to match the v7 layout...

PS: In addition to the 8 I ordered from GS, I ordered one of the v7 units in the plastic case off Amazon, and that one has also been perfect. I had a v5 unit from over a year ago as well and that one is stable too.

I'm running Armbian 4.19.20 on both v5 and v7 boards 1000 MHz... on the right boards it is perfectly stable. I'm the guy who returned 6 of 8 because they would freeze or kernel panic in under 24 hours even with the GS shipping ubuntu... The devices that worked and were stable with ubuntu are stable with Armbian.

Ok, I see there is a kernel patch to swap wan and lan1... so no u-boot twiddling necessary. https://github.com/armbian/build/pull/1244/files Not sure when this will make it into the "stable" release?

New revelation... the v7 of espressobin has flipped the ethernet port order. On v5 they were (left to right) lan1 lan0 wan On v7 they are (left to right) wan lan0 lan1 When I load armbian with latest u-boot (I believe v7 are the only boards with ddr4...) the ports are in v5 order. The v7 ports have the intended wan port separated from lan0 lan1, so they really need to be re-assigned. Is there a way to fix this without rebuilding u-boot?

I also confirmed that settings for eth1addr eth2addr eth3addr have no effect . lan0 and lan1 must be set in interfaces.d files to give them unique MACs.

Eureka! Just found the location of the mysterious MAC! Changed it and it worked!!! The address used was the default in /boot/boot.cmd It looks like u-boot environment is ignored... You can override the default in the armbianEnv.txt file as instructed at the top of the boot.cmd file. added and ethaddr= line and it worked! eth1addr etc. do not seem to get picked up... This all may have been obvious to people more familiar with armbian... sorry, I'm just learning my way around it.