TonyMac32

I leave for vacation. All the answers after the holidays.

Ethernet Patch definitely made my potato solid.  I'm running fresh image now, with consul, nomad, docker and Jira running in a container..  def much faster than on my Opi2e.
 
Thanks for the patches!
 
Linux lepotato 4.14.8-meson64 #2 SMP PREEMPT Sun Dec 24 21:03:07 EST 2017 aarch64 aarch64 aarch64 GNU/Linux  

Ffs there is a Google search function built into this website, use it.

Sent from my Pixel using Tapatalk

Mainline does not support that touchscreen yet, the changes to the drm system from 4.4 to 4.14, and the "special code" used in the 4.4 made me pause before patching any changes in.  There are tons of mipi/DSI patches in the pipework, so I'll have to revisit it.  For now pulling that node is perfectly acceptable.

Ffs there is a Google search function built into this website, use it.

Sent from my Pixel using Tapatalk

Yes. In our beta/nightly repository, updated a few moments ago.  Just do apt update & upgrade

Wrote on mobile

@JeromeB understood.  Patched, tested, no negative consequences, and so far no hangups either.  
 
Is the recent series slated to make it into a 4.14? 
 
[edit] streaming video, 3 ssh sessions (one with X-forwarding), and moving files around in the background and no issues.  
 
Had some time, and added the series of phy adjustments as well to our 4.14.y build, everything is working quite nicely.
 
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.7-meson64 (root@builder) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #38 SMP PREEMPT Tue Dec 19 01:16:29 EST 2017 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] [ 0.000000] Machine model: Libre Technology CC ... [ 17.562193] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=33)  

@JeromeB understood.  Patched, tested, no negative consequences, and so far no hangups either.  
 
Is the recent series slated to make it into a 4.14? 
 
[edit] streaming video, 3 ssh sessions (one with X-forwarding), and moving files around in the background and no issues.  
 
Had some time, and added the series of phy adjustments as well to our 4.14.y build, everything is working quite nicely.
 
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.7-meson64 (root@builder) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #38 SMP PREEMPT Tue Dec 19 01:16:29 EST 2017 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] [ 0.000000] Machine model: Libre Technology CC ... [ 17.562193] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=33)  

Hi Guys,

There was a couple of issues around ethernet on gxl. This may have been the source the confusion.

1) LPA Corruption: Sometimes the LINK PARTNER Advertisement is not correctly sampled: When this happens, you see the link being negotiated at 10Mbps/Full or 10Bmps/Half instead of 100Mbps/Full
This is fixed by https://github.com/libre-computer-project/libretech-linux/commit/04e76dadce3ec09bbefb45fde95580d217fc5c38. I have pushed it to libretech repo because the patch has been accepted by the net maintainer.
It will eventually end-up it linux stable and future kernel releases

2) Net hangs: There are lot of ways to reproduce this issue. What worked best for me was to wget a small file (2kB) in a loop. Downloading large file in background helps.
The problem is coming from EEE and Low power Idle. It should not be enabled or supported by the PHY. However, when reading the related registers, you get 0xFFFF.
This is interpreted as "Yeah ! everything is supported ! go ahead !". The (proposed) fix is to prevent stmmac from trying to activate EEE in RMII mode : https://patchwork.kernel.org/patch/10092657/  
Patch is still at RFC state, which is why I did not push it (yet) to the libretech repo. It should be safe to apply though.

Hope this helps
Cheers
 
 

Ffs there is a Google search function built into this website, use it.

Sent from my Pixel using Tapatalk

Better hope a certain world leader doesn't get wind of this:  "CNX is fake news!! SAD!!"  

That makes me feel so much better... 
 
It just seemed a rather extreme jump, given the usual context of this board ("I bought an $8 thingy and it's not as powerful as my laptop... WHY?!?!?!")

Oh my, have they fixed all the reboot hackery?  Also see:  Giant Heatsink.  
 
And no, even in automotive where last time buys are common, no one is stocking to support "up to" 2 million pieces without guarantees that the parts will be used.  I wonder if that vendor had a falling out with Rockchip.

This works on a voluntary basis, by and large.  The core team is extremely small, and so far the only board on the books with the RK3328 is the Rock64 (discussion should begin soon on Libre Computer's Renegade, but I don't know where that is), meaning it takes a lot of effort and is the only board to presently benefit from the attention.  If the dev's don't have the hardware, or the hardware broke or was changed since introduction, then things come to a halt.  Especially around a version bump where the currently supported boards need to take precedent.
 
The typical reply is donations and hardware, donations and hardware.  Also testing testing testing.  An image can not be thought of as "stable" until it's been tested by more than just the dev team.  Try the image and let us know what the results are, however I'd caution you that this board is very early in development in general, it won't be stable for some time.

Could just put a subscript "Forum" at the bottom right corner of Armbian.

Thank you for the update, I saw the activity in the lists, I should be able to try the patches out soon to see how they work.  For the short term I've been using a wifi dongle.  

BayLibre says they're close to a fix. It's an issue with EEE capability being mis-detected.

Just a heads up, I think the bigger issue between the revision 1.1 and 1.4 is that they removed the "U5" buck AVCC/RTC 3.3V converter, Instead in its place they put a "R9" 0 ohm resistor from the GPIO 3.3v regulator "u55". As such it makes sense that they removed the "Q11" gpio voltage enable switch, since now that switch must always be on.
In testing the voltages, the Rev 1.1 GPIO VCC is 3.37v, whereas the AVCC/RTC Vcc is 3.27v.
For Rev1.4 though, the GPIO/AVCC/RTC Vcc is actually 3.4v.
I am currently removing "R9" from rev 1.4 and installing a diode to drop some voltage. It may help to keep the device from overheating. If that doesn't help, perhaps adding a secondary 3.3v buck regulator can fix the issue.
 
Update: With the diode to drop voltage, the resulting voltage on AVCC/RTC is 2.91V.
This results in the following temp readings stable/finger tested:
19:02:53: 1200MHz  0.71  19%  11%   6%   0%   1%   0%   -2°C
19:02:58: 1008MHz  0.73  19%  11%   6%   0%   1%   0%   -4°C
19:03:03:  240MHz  0.67  19%  11%   6%   0%   1%   0%   -9°C
19:03:08:  240MHz  0.62  19%  11%   6%   0%   1%   0%  -10°C
19:03:13:  240MHz  0.57  18%  10%   5%   0%   1%   0%  -11°C
19:03:18:  240MHz  0.52  18%  10%   5%   0%   1%   0%  -17°C
19:03:24:  240MHz  0.48  17%  10%   5%   0%   1%   0%  -20°C
19:03:29:  240MHz  0.44  17%  10%   5%   0%   1%   0%  -21°C
This leads me to believe that the temperature may not be significantly if at all different between v1.1 and v1.4. It would make sense for the slight voltage difference of voltage on the AVCC pins would change the internal temperature readings. They probably don't have any sort of voltage reference internally, and that would lead to any sort of internal reading based on analog voltages to be affected by voltage changes of the AVCC power.
I will test this with a power supply on the seperated AVCC/RTC to see if it does indeed result in different internal readouts.
 
 
Alright, here's what I found:

All of these results are running the armbianmonitor right after start up and each show a "finger test" draw represents draw on the Avcc/rtc  from the power supply, and is quite stable.
 
Orangepi v1.4 test: r9 removed, AVCC&RTC=3.27 about 50mA draw during test:
Orangepi v1.4 test: r9 removed, AVCC&RTC=3.4V about 50mA draw during test:

Orangepi v1.4 test: r9 removed, AVCC&RTC=2.90V about 40-50mA draw during test
 
Results: The internal temperature sensing cannot be trusted, especially since there is no voltage reference.
Tomorrow I will try to place a 150mA 3.3V LDO regulator instead of "r9" and see if I can find a way to actually test temperature.

PS: I would add images if I could figure out how to do so outside of hosting them somewhere else.
 
Sidenote:
"R9" is glued down, so to minimize chance of lifting pads when desoldering try this:
1- apply generous amounts of flux from flux pen.
2) use solder wick to remove as much solder as possible
c Once all the solder is gone, rotate the part 90 degrees with flat end needle nose pliers while slightly pushing into the board.
 
If you managed to get enough solder off, the part should break free without lifting the pads. And if they do lift, you can always solder onto the test points on the board.

I built a cosmic ray detector once, good chance to play with photomultiplier tubes.  However it's hard to be sure unless you've tuned it right, random gamma events from the long decay chain of Radon, for instance, can make a mess of your data and make you think the cosmos is even noisier than it really is.  The important part about them though, is that they don't come from here, they also don't come from the sun, by and large.  And bit flips in extremely high density media has a lot more to do with the probability of an electron existing where you think it does, or not. 
 
Google things like "hot carrier injection" (Safe for work, I promise ), and electron tunneling.  Just because we will it to be so with our machines, sometimes nature gives us a hand gesture we wouldn't want our children to see.  And sometimes, the carriers don't stay "stuck" in jail where they belong.

I agree, but wish we had a way to "document-ize" the tutorial after all the discussion.  You get 40 pages of talk on a tutorial and it's easy to miss the important parts.
 
Yes, there is.  I think we run into trouble that there aren't many maintainers to begin with, and we range from " This is good enough I don't need feedback" to "I want 100% absolute direct democracy on every decision".  This is difficult, and there are pros and cons to both.100% direct democracy does quite literally mean nothing gets done in a reasonable time, but everything will be more stable.  "Good Enough" gets you more bugs, but also more on-time releases and a sense that you're "doing something" to the general public.  (See the criticism Debian gets about their definition of "Stable")
 
There is one thing I can say that is hard to dispute:  I can test something pretty thoroughly on my hardware in my laboratory with my equipment.  That doesn't mean it's going to work for anyone else repeatably.  So I test, and I commit the changes.  My changes are immediately live, there is no means to "trial" a change.  This is a discussion for another thread, but we should have a stable "release" branch that only gets updated for bugfixes.  Then our download page would have "Stable Release" and "development" images.  People want to use dev images?  Ok, but know that a 5.37-beta release may not be stable, even if it is a legacy kernel/etc. 
 
 
For the Website: I think a CMS is best.  However, if the primary maintainer of the website is not fond of that idea, then a set of templates and a github would be a wise alternative.

Well, I do agree we need to stick to web page topic, the other stuff is an elsewhere conversation.  
 
So I spent some time in the documentation github, I saw changes go live instantly on the documentation page, nice.  What is the rate of update on the webpage itself?  I added the ethernet issues to the potato board notes, it wasn't there initially, but was several hours later.  I like the GitHub --> Web page link, that allows for direct community contribution via pull request, and allows for rollback of mistakes.

I have thrown myself out of the forums at least 6 times today by clicking on the "Armbian" banner image.  

I agree, but wish we had a way to "document-ize" the tutorial after all the discussion.  You get 40 pages of talk on a tutorial and it's easy to miss the important parts.
 
Yes, there is.  I think we run into trouble that there aren't many maintainers to begin with, and we range from " This is good enough I don't need feedback" to "I want 100% absolute direct democracy on every decision".  This is difficult, and there are pros and cons to both.100% direct democracy does quite literally mean nothing gets done in a reasonable time, but everything will be more stable.  "Good Enough" gets you more bugs, but also more on-time releases and a sense that you're "doing something" to the general public.  (See the criticism Debian gets about their definition of "Stable")
 
There is one thing I can say that is hard to dispute:  I can test something pretty thoroughly on my hardware in my laboratory with my equipment.  That doesn't mean it's going to work for anyone else repeatably.  So I test, and I commit the changes.  My changes are immediately live, there is no means to "trial" a change.  This is a discussion for another thread, but we should have a stable "release" branch that only gets updated for bugfixes.  Then our download page would have "Stable Release" and "development" images.  People want to use dev images?  Ok, but know that a 5.37-beta release may not be stable, even if it is a legacy kernel/etc. 
 
 
For the Website: I think a CMS is best.  However, if the primary maintainer of the website is not fond of that idea, then a set of templates and a github would be a wise alternative.

I think how to categorize the boards is a separate discussion, I'd link it in closely with the matrix of kernel support I've mentioned elsewhere, then that could be searchable via a specific function (like a filter:  "I want a mainline supported USB3 Gb Eth 64-bit quad core")

I built a cosmic ray detector once, good chance to play with photomultiplier tubes.  However it's hard to be sure unless you've tuned it right, random gamma events from the long decay chain of Radon, for instance, can make a mess of your data and make you think the cosmos is even noisier than it really is.  The important part about them though, is that they don't come from here, they also don't come from the sun, by and large.  And bit flips in extremely high density media has a lot more to do with the probability of an electron existing where you think it does, or not. 
 
Google things like "hot carrier injection" (Safe for work, I promise ), and electron tunneling.  Just because we will it to be so with our machines, sometimes nature gives us a hand gesture we wouldn't want our children to see.  And sometimes, the carriers don't stay "stuck" in jail where they belong.