TonyMac32

I have to agree with@chwe on this, I am in the automotive industry, not only would I be fired for such documentation of a design, there could be federal charges brought against myself and my company ending with me in jail if incorrect documentation could be linked to a failure or unexpected behaviour. Not to mention losing all OEM business, etc.

It is not such an impossible task to document properly. But attacking anyone who points out factual errors in your paperwork causes animosity and people will refuse to support these products. Trust me, I am no stranger to poor documentation. But at least for the ASUS Tinker Board the problem is missing documentation, not incorrect documentation. Were it incorrect I would have immediately recommended Armbian drop all support for the board, no matter how popular it may be.

Now, as an engineer I am accustomed to dealing with suppliers. In this situation, that is your role. You are a supplier of single board computers to a marketplace. That gives the user (customer) a certain amount of agency over you, the customer can require correct documentation, the customer can provide negative feedback and refuse to use your product. As a supplier it is your duty to provide a product the customer wants. In the single board computer world that is more than a board, it is also the means to use it. Your product cannot simply be defined as a board, your product is a board and a manual. And that manual needs to make it possible to use the board. The manual includes complete and correct schematics, diagrams of all exposed connections, a basic board support package (device tree or equivalent, vendor-specific drivers, uboot if not mainline, etc)

As you have pointed out, most SBC suppliers in this market have flaws. But I have seen none that are outright confrontational and generally unprofessional. Do you think I don't have customers and coworkers just as disagreeable as Thomas is capable of being? Of course I do, many far worse actually. Do I respond the way you do? No, or else I would not have a job. Do I always agree with the magnitude and force of Thomas's quick anger? No. But I certainly understand it. I actually refused to reply several times during this thread because I felt my feedback would be less than professional. However, my reserved tone has apparently caused some confusion which I felt it necessary to clear up.

I want to see a good competition between board makers, and the obvious benefits that come with it. So to that end I want to see you succeed. However, for that to happen you need to also compete in documentation. You have said you will, but be aware I will not engage in any development, privately or for Armbian, until there is some proof of that effort. A big step would be addressing the concerns you have heard here so many times that I'm even tired of reading about them.

[/rant]

Sent from my Pixel using Tapatalk

Right, my comment on eMMC is purely about reducing/removing interconnects, the primary failure point in most systems.  Speed is secondary in such embedded systems.  I would ideally use the SD card only for data storage, for instance data logging/etc.  

Indeed you do, however it does not have "CON4" anywhere on the board silkscreen that I see, and being a 2x2 header alignment is still a bit of a question, especially when Pin1 is marked to be on the right-hand side, which is non-conventional compared to the rest of the board.  Not saying anything is inherently wrong, the schematic is there, is labelled, but I for one, a senior electrical engineer, did not notice it, instead seeing an unlabelled 2x2 on the physical device.  This should be on your page explicitly labelled, and probably a silkscreen adjustment made.
 
[wishlist]
 
Now, were it a 2x3 with 2 of those pins being a V_in....  Now that would certainly be useful and meet the approval of many.  Not to mention making orientation a non-issue as it would then be non-ambiguous.  ;-)
 
[feedback]
 
Do the various test points exist in hardware, such as the "TV-out" (TP8?)?  If not they need removed, simply because you are referring to the schematic as an ultimate resource (as it should be)  That said, TV-out is a Pi Zero feature...
 
If you are open to a feedback, I would say a good variant would be one of these without wifi, but instead with the additional USB's available via header, a position for a barrel jack or direct-solder power input, and an eMMC.
 
 

I've added RPi 7" DSI touchscreen support to the 4.4 kernel, I will work on patching it into mainline as well, but no guarantee, it is not the cleanest of drivers (requires modifying the dw-mipi-dsi.c file), and this patch is MiQi safe.
 
This would have been done earlier, but I had to make sure it would work by declaring the hardware in the device tree instead of explicitly in the kernel source. (and make sure it didn't break the MiQi)  As it turns out, I was incredibly overthinking the problem, cheers to the Linux kernel devs.
 
Tested OK with this configuration: 
Tinker with DSI Display Tinker with DSI Display and HDMI display (displays are "on top of each other" on first boot, drag the smaller display around in the desktop settings and you have an extended desktop) Touchscreen driver is not robust against this configuration.  It tries to cover the full extended desktop. Tinker with only HDMI (no ghost devices/errors/crashes. Tested to be sure the drivers could cope with not finding the hardware, as the device tree entries are still there) MiQi (as it does not have the DT entries, merely a test to make sure no source/driver interactions)  

We have search feature: "mali mainline" would give you something useful. I merged it with an existing topic.
https://www.armbian.com/search_gcse/
 

To develop, test and debug dependencies and finally implement this feature cost/would cost roughly 5.000 (depend from which perspective you look) volunteering working hours from experts in the field. I am always happy when we receive a donation since it is a rear event. Sometimes people donate a box of beer which makes my wife angry and sometimes pcs of hardware.

Donations are like love. Unconditional.

OK, testing against MiQi to make sure nothing outrageous is going on, screen is working with DRM rather nicely.  Plugging in the HDMI at the same time is...  well unique, the 7" display just lives in the top left corner of the larger external display, and the touch feature applies to the full larger desktop.  In any case, if it passes testing on 4.4 it might be fun to get it to work on 4.13/14
 
[Edit]  MiQi is working perfectly, no issues with the entries in the Tinker DT if the screen is not connected, I'll upload the patch.

Available for:
 
4.13.10 cubox (Cubox-i, Hummingboards)
4.13.10 mvebu64 (Espressobin)
4.9.58  odroidxu4 (Odroid XU3/XU4)
4.13.10 rockchip (Tinkerboard, MiQi)
4.13.10 sunxi (All Allwinner 32bit boards)
4.13.10 sunxi64 (All Allwinner 64bit boards)
 
https://dl.armbian.com/_misc/realtime-kernel

Requirements:

- Armbian OS. Ubuntu or Debian bases.
- root credentials

Download: *dtb and *image packages at a minimum and install them with dpkg -i *.deb ... If you want to stay on this kernel, freeze upgrades in armbian-config -> system -> freeze kernel upgrades.

Remember that those kernels are bleeding edge, made from upstream sources and may have troubles. Consider them as is/experimental, without end-user support. If you want to build them - patches are present but .disabled and might not apply cleanly with more recent sources without adjustements.
 
What is RT?

This is being investigated at Amlogic.

Topic covering feature updates/bugfixes.
 
Sep. 29 2017 - HDMI hotplug script/udev added for Mainline.  Switching monitors no longer results in a necessary reboot.
Nov. 22 2017 - Dev updated to 4.14 with Libretech patches
Nov. 23 2017 - Next updated to 4.14.y with Libretech patches  <- wait for nightly, not on download page Active download
Dec. 18 2017 - Patch uploaded to fix Ethernet instability: commit
Feb. 04 2018 - Ethernet LED's fixed in repo. commit
July. 08 2018 - Next is kernel 4.17, HDMI audio fixed
 
[bug] Dec. 20 2017 - Init 0 results in reboot
[bug] July 8 2018 - Kernel 4.17 cpufreq throwing errors setting clock speeds, even after BayLibre patch. (board was initially unbootable, patch fixed that)

Did you try using the rk3288-tinker.dtb provided with my build, or a 4.14.x ready rk3288-miniarm.dtb ? If you use a 4.13 or lower version DTB, it might fail to boot due to Rockchip 32 bits DTS using 64 bits addressing now, in order to use LPAE on some 32 bits boards. LPAE provides the ability to use more than 4 GB of memory on 32 bits systems, through magic, memory windows and ugly hacks.
 
Anyway, I tested my latest release (4.14.0-rc7) with glmark2 and the Rockchip's r14p0-wayland user-space binary drivers and it works. I'll try to install Rockchip xserver and test glmark2 on X11 this week, if I got the time.
 
During these tests, I discovered the magic of chvt, which changes the current virtual terminal displayed on the screen, which is very useful when you have control on a machine with SSH access, but no USB keyboard plugged on the machine, and want to switch to a terminal from X11. So basically instead of trying to find a keyboard, plug it and hit CTRL+ALT+F1, you just have to type :
sudo chvt 1 I also checked that using a shitty micro-USB cable will cause the MiQi to reboot instantly when doing 3D intensive work. Yay !
Remember kids, don't do drugs use bad micro-USB cables !

I downloaded the git repo of Myy and copied some files into armbian eg. zImage. I believe because of the sym-link it looks like it is 4.13 but the date of the changed
 
Nightlys are already 4.14 rc6

Circling back on this one, I've had quite a lot to do around the house with winter approaching, here in a few weeks it should settle down. (Just in time for the holiday season here in the US...)
 
@Myy, thanks for the info, I will attempt this with the DT rather than the explicit code.  I might drop a line to Wzyy about it too, since they are now using DT overlays on their kernel.  What this means is that, for now, this would have to be enabled via editing the DT file by the user after I get it working in this manner.

That probably won't work, unless both kernels were built from exactly the same kernel source. Additionally, drivers in LE reside in read only part of filesystem. So you have to have LE sources and put those drivers there. But since you have to build whole image, it makes much more sense to add those drivers as a source in build system and build them.
 
BTW, part of LibreELEC team (me and omegamoon (builder of ugoos images) included) works on official LE support for Allwinner, Rockchip and Amlogic devices. RK3288 is included in that effort, so if you can wait a bit, you will get official LE image. You can ask at LE forum in Rockchip subforum what can be done. Please specify details, for example exact tablet model, which wifi driver you need, etc. If problems are minor, like enabling already present wifi driver, they will probably be resolved quickly, but of course I can't guarantee that.

The Arm Trusted Firmware memory issue will not be fixed in the 4.14 LTS kernel, which is a bit curious, it's a pretty significant flaw and renders the Meson-GXL family of boards to be little more than paperweights.  I glazed over the bit where it's queued for 4.15.  Glad I didn't hold off patching Dev. @balbes150 might be interested in this as well.  It's a small patch, so not a terrible tragedy, unless you don't know it exists...

Found it.
 

I've created a wiki for the libre computer which has instructions for getting started, location of downloads and pinout diagrams.
more information here
http://wiki.loverpi.com/sbc-brand:libre-computer

UK Server deployed. Details PM'd

My RTC is atached to GPIO 3 and 5
 
result of lsmod :
 
Module                            Size  Used by
snd_soc_hdmi_codec    16384  0
mali_kbase                 339968  0
dw_hdmi_i2s_audio      16384  0
uas                                20480  0

If only any wifi were so simple...
 
 
https://github.com/fifteenhex/xradio
is an example of someone working on this.  The readme excerpt below came from there:
Also: The xr819 chip/firmware drops tons and tons of frames with FCS errors and this makes performance horrible at best. Most people have lost interest in having anything to do with the xr819 because of people being idiots and demanding that issues that are incredibly hard to fix without documentation be fixed because they spent $8 on a board and somehow people that got exactly zero of their $8 are responsible. Moral of the story: If you're going to post nasty things on the interwebs and demand people fix stuff because reasons at least have a bunch of packet dumps etc and have some idea about what you're talking about.  

Basic status update here (31 followers of thread) 
 
All mainline kernels support wireless All kernels reboot properly Mainline kernel HDMI hotplug now supported  

Alright, for those who build it themselves, the hdmi hotplug script has been added to the build script, nothing for you to do but enjoy being able to unplug your monitor without rebooting your board.

Hi,
 
Mainline Linux has support for the SCPI Temperature Sensor, please check in /sys/class/hwmon/hwmon0/temp1_input
 
For the hard crash, looking at the logs seems to indicate a memory issue, we will investigate further !
 
Thanks,
Neil

I havent tried Armbian yet but I had the same problem when I created a buildroot based firmware using eudev.
 
I added a new udev rule:
SUBSYSTEM=="drm", ACTION=="change", RUN+="/usr/local/bin/hdmi-toggle" in a new file (hdmi.rules) in /etc/udev/rules.d
 
Then save the bash script below to /usr/local/bin/ which will be triggered by the udev rule and toggle the display
#!/usr/bin/env bash USER="$(who | grep :0\) | cut -f 1 -d ' ')" export XAUTHORITY=/home/$USER/.Xauthority export DISPLAY=:0 ########### Settings ########### # Use 'xrandr' to find these DP="DP-1" VGA="VGA-1" HDMI="HDMI-1" INTERNAL_DISPLAY="LVDS-1" # Check /sys/class/drm for the exact location DP_STATUS="$(cat /sys/class/drm/card0-DP-1/status)" VGA_STATUS="$(cat /sys/class/drm/card0-VGA-1/status)" HDMI_STATUS="$(cat /sys/class/drm/card0-HDMI-A-1/status)" # Do no change! EXTERNAL_DISPLAY="" # Check to see if the external display is connected if [ "${DP_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$DP fi if [ "${VGA_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$VGA fi if [ "${HDMI_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$HDMI fi # The external display is connected if [ "$EXTERNAL_DISPLAY" != "" ]; then # Set the display settings xrandr xrandr --output HDMI-1 --auto else # Restore to single display xrandr --output HDMI-1 --off fi exit 0  

That's exactly what I did...  I maintained some servers for fraternities when I was in college, I learned a few relevant tidbits.  The RAID box I have has eSATA as well as USB 3 and presents itself as a single drive rather than as a port replicator.  But yes, I'm sure that's not the best USB 3 to SATA bridge in there, it's on its fifth year, any trouble and I may simply go to a pair of mirrored redundant disks without all the overhead.
 
 
My current setup is designed around the idea of highly disposable clients with permissions, so centralized staorage was key.  However, it is, to the fully functional clients, as you suppose:  they have full copies to reduce traffic on the network itself, synchronized for changes.
 
For the Rock64 I've seen their little hat with the fast ethernet and sound, I'd be more interested in a fast Ethernet to cover an HDHomerun in a dedicated fashion.
 
For Plex, and I can say this as I run it, I hate their transcoding scheme.  I think they should have that portion of their work wholly documented so interested parties can improve hardware support.  As it stands the Plex transcoder is 100% software on all platforms but select PC's (which need this advantage the least)  This is important for the next point:  The XU4 is capable of transcoding in software, at least with my really stupid cooling system (what throttling?), I am not sure the Rock64 will have that ability.  If the transcoder were truly open for development, it would be possible to have transcoders for these lightweight ARM devices.  This is, of course, unimportant if all of your devices support direct streaming of everything you want to watch, or you're not going to stream outside the home.  I've been watching Emby develop, I may need to try it out if I can get ffmpeg working properly on Rock64 and Tinker Board, having a more or less shared vcodec system. (Tinker is more primitive).  When I say "I" it's actually more likely @Myy, who is working to get it working on mainline while I cheer enthusiastically.
 
This board has a barrel jack, so that's a positive.  It is tiny though, so I can't be certain it has a very high current rating, often the miniature ones top out at 1 to 1.5 amps.  I have not done my normal power testing on the Rock64, but I doubt it will disappoint.
 
Type C will not be a solution for a few years yet, because of the saturation of microUSB and the availability of $1 for three adapters to USB Type C.  Sadly the reality will be properly designed boards being powered via a meter long AWG 24 cable at 5.0 Volts through a microUSB to Type C adapter. 
 
I have a wired home network, not for speed but rather for reliability, I have many neighbors, all with wireless, and several who think that Channels 2, 7, etc are valid for use.

OK, got it compiled into 4.13.3:  http://sprunge.us/aBaA
 
Both HEVC-service and VPU-service available in /dev/
 
[Edit]  I forgot they were using Stretch, tried to install the Rockchip Mali driver and nuked my xserver.  Tried to install their xserver but Xenial does not support a couple libraries they now need.  Building a Stretch image to give it a try.  I'll have to try this on 4.14 next as I'd rather not stuff (this level of) experimental code into Next.