TonyMac32

I have not seen it, however it's not impossible, the patches themselves refer to the sound driver as WIP, like I noted in the first post (which I update periodically), I am getting a left/right channel swap over HDMI. Those errors do look like that is something to do with ALSA itself or the USB line in (I'm assuming since it's a source), since the error is mirrored across both devices. I'm glad to see the networking appears to be resolved, so far I have not had any issues either.

Mine are dark as well, it's low on the list but yes, a problem that will need addressed. Unrelated to ethernet, but will add to the proper thread.

You could do an iperf test between the potato and a "known good" device. At the moment I'm trying to figure out the ethernet MAC issue, ideally I'd have the system use the efuse, but I think these SoC's come "empty"as far as MAC address goes. Could you give me the output of hexdump /sys/bus/nvmem/devices/meson-efuse0/nvmem For all 4 boards? (unless all identical outputs, then 1 will do. ;-) My guess is you'll get [BL31]: tee size: 0 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 00000c0 meaning all 0's all the time. Using U-boot I manually stuffed a value in there, the command was 'efuse write 0x34 0x6 <6 characters ASCII >' so now I get this result: [BL31]: tee size: 0 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0000030 0000 0000 3561 3462 3363 0000 0000 0000 0000040 0000 0000 0000 0000 0000 0000 0000 0000 * 00000c0 Be careful, I haven't tested if this is one time programmable or not. <<--- warning stands I will try to get u-boot to set the ethernet mac address using the efuse, and work out some logic for either letting the user set it, or have it burn the first random it produces into the efuse and then use it permanently. I'm not the expert on this, so feel free to bash the idea/mock me/etc. pseudo-code: ethMac = efuse read 0x34 0x6; if(ethMac == 0) { ethMac = random_address; efuse write 0x34 0x6 ethMac; // <-- will have to work out the ASCII wrinkle } setEthernetMacAddress( ethMac ); The savvy user could set their own and this would not conflict.

uname -a Linux lepotato 4.14.7-meson64 #51 SMP PREEMPT Tue Dec 19 12:33:49 CET 2017 aarch64 aarch64 aarch64 GNU/Linux Is what mine says after update.

I was going to say 6- or 8-pin PCIe power would be a good connector, but that would be contrary to the cable standard, adding 5V. Although, the cables are easy to get without chopping things up...

@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 @Tido, I was just pointing in the general direction of all the info I had. I haven't done anything with Le Potato as far as GPIO is concerned. The info you linked is specific (at least partly) to i.MX6, so you may be treading some deep water trying to read that across to a different SoC.

Thank you @JeromeB, I was looking at your patches this morning (EST Detroit), was going to try them out in a few hours. I also saw you adding yourself to the "Blame List" for the driver. Thanks again!

Ffs there is a Google search function built into this website, use it. Sent from my Pixel using Tapatalk

Last bit of Info: Compiled it without it being a module, verified the phy driver is being loaded, overlooked "Meson GXL Internal PHY 0.e40908ff:08". Problem persists. [ 1458.180440] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 1458.251686] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=POLL) [ 1458.263053] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW [ 1458.263447] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 1461.315784] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 1461.315842] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready The Ethernet network simply hangs, no data moves but the link claims to be up. Disabling/re-enabling networking entirely renegotiates as you see above.

@Da Xue I'm looking into some mdio errors I'm getting at boot, I'm not certain the PHY driver is being loaded, of course how ethernet works becomes a question, unless the meson8b-dwmac platform driver <--- loaded because Le Potato --> Meson GXL --> Meson GX "compatible" device tree declaration is using a generic driver (which appears to be about 90% correct given the gxl driver, most of it being "genphy_x": static struct phy_driver meson_gxl_phy[] = { { .phy_id = 0x01814400, .phy_id_mask = 0xfffffff0, .name = "Meson GXL Internal PHY", .features = PHY_BASIC_FEATURES, .flags = PHY_IS_INTERNAL, .config_init = meson_gxl_config_init, .config_aneg = genphy_config_aneg, .aneg_done = genphy_aneg_done, .read_status = meson_gxl_read_status, .suspend = genphy_suspend, .resume = genphy_resume, }, }; I will take a closer look.

I have been using the device as a desktop replacement for about a week, so I just unplugged my Wifi and went straight to ethernet-only, the connection went down in a matter of minutes while streaming videos on Youtube. I switched to audio streaming and web browsing to the same result. [EDIT] It stuck out to me that this patch appears to address link negotiation problems (good, we don't want those either). The issues I've seen (and seemingly the others in this thread) revolve around losing functionality after link is established, so potentially an entirely separate issue.

I'm only seeing this one.

One patch, I will repeat with both.

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?!?!?!")

It would be best if, as mentioned earlier, you test the voltage at the GPIO pins or the USB. I reliably get a 0.1 to 0.2 volt drop across a micro-USB cable. It's also important to see that supplies, especially "Black cubes" and "wall warts" tend to run high until placed under appropriate load.

I'm familiar, I was using GPIO to try to make the Bluetooth work on Tinker mainline. http://www.mediafire.com/file/sj8doy9vcsgg290/Amlogic_S905X_S905L_GPIO_User_Guide_V0.2-Wesion.pdf Google is your friend. Sent from my Pixel using Tapatalk

Remember the 5V, 3.3V, and Gnd lines not being software controlled. ;-) Sent from my Pixel using Tapatalk

Interesting, but the RK3399 is $$$$ by comparison, or did that change?

I would expect that that heat is coming from poor design or poor components, either of which could cause a spontaneous "thermal event" @Igor I think we need to add a fire emoji, I've seen a few places it would have been handy. ;-) Like I said about uptime, it has never crashed. I've taken it offline to move it, rearrange the cabinet, security updates, etc, but the system is quite stable. My home is not a production environment, so things get moved around quite a bit and I constantly tinker with things. The XU4 is liquid-cooled, for example (runs 28 C at idle). <--- Waste of time, but it's what I do instead of TV and (too many) video games

Baylibre has been labeling all of the GPIO in the device tree. https://github.com/BayLibre/libretech-linux/blob/389b9471d865483aebc681fd3a9e20b61934c82e/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts#L216

I gave the necessary warning concerning that supply, the OP is a gambler it would seem. Even a couple watts of waste energy when providing 15Watts max is a warning sign. It should at most get "warm", even if you plugged every single air path on it. See if you can get something like an RS-25-5 Mean Well, $14 USD, and at 5 amps you can power everything at maximum draw. (Adjust to 5.25 volts of course to account for high contact resistances known in micro USB). As far as HC1/XU4 is concerned, my only shutdowns occur for update maintenance. I've had 60+ day uptimes running as a file and media server transcoding videos and TVHeadend DVR. Sent from my Pixel using Tapatalk

Never turn that supply on again, and throw it in a dumpster. Unless fire is something you're particularly fond of. Get a mean-well, they are much better and not terribly expensive if you want to stick with an adjustable chassis supply. The "flapping" was most likely high-voltage transients your meter wasn't fast enough to display.

After applying https://github.com/libre-computer-project/libretech-linux/commit/10e57db5d30693ef4e08d0611e62c0d61a97e419 I still got a link hang/failure relatively quickly, however after disabling/re-enabling networking I then streamed a bunch of video and music and am still up and running. (Hung twice more while typing this). This has been a "forever" problem with GX and GXL it would seem, http://rglinuxtech.com/?p=1831 The author of the above link disabled flow control and seems to have "fixed" it at the expense of performance. I am going to test it's effectiveness (FAIL), since a fix may be some time, as the phy doesn't sound amazingly well documented.