TonyMac32

I was about to check for it's existence, but decided to check the forums first. Alright then. As for the patch, these are sort-of-WIP patches from BayLibre, who is working to get GX/L/M mainlined. I expect there will be some rough edges. ;-) Since you completely revised the patch set, make sure you didn't lose anything, I haven't thoroughly gone through the C2 patches to see if anything special is in there that would benefit the other Meson64 boards.

The short answer is no, but I'll take a look at what I have in the K2 / Potato patchset, I haven't looked that closely since more basic functionality was missing/broken. The C2 is presently set up as a different kernel config as well from the other meson64 devices, so I'm not certain where it's development stands, only having access to the K2 and Le Potato, hardware wise.

The C2 is a gxbb board, it would be better discussed in the K2 topic. Me being a smartass aside, I will take a look. For Le Potato I'm going to be testing out the Ethernet patches to hopefully cure the network dropping out. *AT YOUR OWN RISK* You may be able to test the nanopi K2 image on the C2, they are both GXBB, I'd recommend comparing the device trees to look for any issues.

Like Le Potato, status of support. Unlike Le Potato, WIP board without official support, 90% of this is incidental to improved mainline support/easy adaptation of fixes for other boards. Current next image kernel: 4.14 Dec. 14 2017: Functions working for me (N=1 sample size) WiFi functioned for me out of the box. HDMI (I added this functionality some time ago) HDMI Sound (Added as of 1:45 Dec.14, not part of any image/build yet) USB Ethernet (no long-term stability testing yet) Jan. 24 2018: small bugfix Board now reports 2 GB RAM instead of 1 July 8, 2018: "Next" kernel (4.17) bugfix HDMI audio repaired (in build system, images not built yet) DVFS better, but still throwing errors [BUG] No USB on K2.

@Neil Armstrong I'm looking for others to verify this, but on my setup the left and right audio channels are swapped over HDMI. I verified it wasn't my monitor/headphone configuration by simply changing the monitors selected input to my main computer, where the channels were correct. I am also seeing a random MAC address, is there an official fix for that, or is it a workaround situation?

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.

K2 images built with kernel 4.14, test away: https://dl.armbian.com/nanopik2/archive/ Build includes the workaround for the memory allocation issue that would crash the system previously. WiFi is not yet working out of the box, it should be as simple as adding the firmware. It works, @martinayotte

What image is this? You're not getting into Uboot with the info pasted. A corrupted SD card is possible.

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.

Great observation.

The Amlogic kernel is significantly modified from mainline, so the workaround kernel patch mentioned earlier doesn't apply to mainline, we'll have to wait for BayLibre to address it.

I would recommend sticking with Next if you're using the device as a daily driver, especially since Dev on Tinker Board is almost always an RC candidate kernel (that comes with it's own bugs separate from anything this project may do.) I would double check, but I think Next image is now built with 4.14.y LTS kernel

I don't have the board in question, however it is specifically "WIP", meaning major functionality can be completely absent.

Updated OP with "real world" use findings. System stability with micro USB has not been a problem as long as SD is used for file system thanks to the RK808 buck converters and LDO's, however anything attached to USB can fail/detach-reattach depending on system load. I would expect longer term testing could show some HDMI issues as well due to 5V requirements.

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

Up to 4 GB RAM, nice. I don't believe the RK3328 (Quad core Cortex A53) is capable of pulling the kind of power the RK3288 can, so that shouldn't be as terrifying a prospect on microUSB (and to be fair, I've been running my Tinker Board on microUSB for over a week just to see what would happen, even plugged my cell phone into it). The campaign says this was done in conjunction with the Firefly board designers, explaining the name I saw floating around for a while. It's using a Rockchip PMIC, from the look of it. Probably RK805 like the Rock64. [edit] <--- The populated part is seemingly ADC, put the unpopulated part appears to have "P"s... could it be the elusive power header? no, but system control buttons I think. While that would be amazing, I'm not going to hold out too much hope. Would be interested in looking at these.

I got the connector housings and terminals in, and remembered immediately why I always try to buy this stuff assembled. It's a lot easier when it's not my money I'm spending on things. I made a simple wired harness nothing to really see there, the spec for these is 22 AWG, but I think if you've a steady hand with a solder pen you can go 20. The contact with the pin is far better than USB as well, so these could most likely serve as power. Now, I also like to make things simple when I can, so I did this: I am certain it is easier to do this on wires, But I couldn't resist. I might look at a small PCB to make it FTDI Friend compatible. Yes, I know that is a FriendlyARM board, but I realized I didn't have a 1.8V UART laying around...

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

Not if you keep the supply at or below 5.25 volts

5.25 V is the spec maximum for USB devices, and the Tinker Board 5V input rail goes straight to the USB. Also, every interconnect in a circuit is a tiny resistor, and results in a small voltage drop. The higher the interconnect resistance, the higher the drop. Even powering through GPIO you are only using 2 pins to carry several amps, which is still not incredibly ideal, even though it is hugely better than using the microUSB. TL;DR: If you have 5.0 Volts going into the tinker board, you will not have 5.0 volts at the USB connectors, ethernet, etc. I use 5.25 as it is within specification and allows some immunity against hot plugging current-hungry USB peripherals.

Well, if you have 16 or 32 MB of storage, that might be important. ;-)

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.

Thanks for the reply, I was wondering about the driver. ;-). Even in my test equipment I run them 4 bit, it's just easier wiring. Sent from my Pixel using Tapatalk

2x16 I2C interface? Interesting. I was confused until I saw the picture, the HD44780 interface for those now has a kernel driver. I need to look at it and see if it can be run in 4-bit mode or if it has to go 8-bits wide. I've been lazy, I have a drawer full of the parallel displays... (good and cheap, and I'm usually using Cypress PSoC 5 controllers with tons of I/O)