pfeerick

There is some movement upstream https://www.debian.org/vote/2019/vote_002

(placeholder for a Board Bring Up thread -- now just collecting random nonsense)
 

 

 
Board arrived today. Running with ayufan's Debian 9 image (using 1.8/1.4GHz settings for the big.LITTLE cores for whatever reasons instead of 2.0/1.5GHz) I checked for heat dissipation with Pine Inc's huge heatsink first. Huge heatsink combined with thin thermal pad shows really nice thermal values:
 
below 50°C when running cpuburn-a53 on two A53 and two A72 cores in parallel with a fan blowing above the heatsink's surface Board in upright positition still running same cpuburn-a53 task without fan after 20 minutes reports still below 85°C even if heatsink orientation is slightly wrong  
Summary: passive cooling is all you need and you should really spend the additional few bucks on Pine Inc's well designed heatsink since being inexpensive and a great performer.
 

there you go.. (should be more or less correct, cause only @jmmc works on such features.. )
 
sure, a not powered board doesn't need much power...  If you want mainline on it, the things you're interested in might come in one or two years (just my opinion)...  To my knowledge, mainlining H6 is still a 'one-woman-show', so better hope that she doesn't looses interest in doing all the work.  

Because Linux support is not mature for the H6?  It's hard to release a distro for something that doesn't have proper kernel support. :-). 
 
@Vincen, The Asus Tinker Board, and MQMaker MiQi have experimental video decoder and GPU support.  I'm not as familiar with the other boards to know what they can and can't do in that department.

@AnythingIsFine Ouch! That sounds like me with the raspberry pi... when the recent 'disabled by default' behavior of the SSH... scratching my head to work out why the SSH wasn't working, and I'd firstly forgotten to make the enable file, then made a typo in the filename...
 
At least it's working now!
 
Hm. so the artful images... interesting... will have to poke around and see why it changed. Be handy to port that back to other images. If the artful images are using the kernel that supports it, it could be signifying disk activity...
 
 

@pfeerick
 
Thank you for your time! On the other hand, I do apologize for wasting it.
 
I managed to boot up Armbian on my Rock64 and figured out that the issue was between the keyboard and chair, namely me.
 
I am running only headless boot on my SBCs and I just configure a static IP after flashing the respective image, which I later use SSH into post boot.
 
On ayufan's Ubuntu Xenial/Artful I just edited the '/etc/network/interfaces.d/eth0' file to achieve this, but when browsing the files after flashing the Armbian image, I noticed the "armbian_first_run.txt.template" file and decided to use this option instead... I edited it to boot 'eth0' to a static IP which I would use to SSH into it, just to test it out (nice feature by the way, very Raspbian-e)
 
Of course, I edited the file accordingly, but simply forgot to rename it to 'armbian_first_run.txt' so it may be found and read and as such the IP I set in it was not configured, hence I could not ping the IP I set up.
 
This mistake, coupled with the fact that the red LED was constantly on as opposed to flashing quickly during boot and then being turned off, lead me to *mistakenly* believe the Armbian image would not boot of my eMMC.
 
 
I think this is default behavior on Etcher on Windows/Linux.
 
When flashing an image using Etcher on my Fedora 27 Workstation computer there is no validation happening post flash process, or at least its very subtle as you point out...
When flashing an image using Etcher on my Windows 7 Enterprise SP1 computer, a validation step occurs post flash process, which roughly takes as much as the flash process itself.
 
 
As can be seen in the below link, the Ubuntu Artful image does cause the red LED to blink during boot up and turn off once the boot process is finished.
 
Artful-minimal-rock64-0.5.15-136-arm64 - Boot up LEDs
 
The Armbian image on the other hand, does not have the same behavior and the red LED just remains on the whole time, which is expected behavior according to this post (your response)
 
Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124 - Boot up LEDs
 
I wrongfully assumed that the red LED on the Rock64 had the same behaviour as the green one on the the Raspberry Pi 3B as described below.
 
Source.
 
 
P.S.
 
I noticed the Rock64 Armbian image is still in its testing phase...
If there are certain tasks/test cases the good folks at Armbian would need extra help to test/implement, please let me know where I can sign up to help!
 

Development versions without active DVFS are usually clocked lower so performance wise we are not there yet. Reboot/power off troubles ... noticed.
 

Yes, ack-ed. I am waiting for another big chunk of free time to dive back in and try to fix this. I also hope that someone else will join and try to move it forward.  
 

Support is enabled in configuration but it looks like implementation on this board needs few adjustments ... Thanks for trying out.

I am investigating a weird issue I have with SOPine modules at the moment, GbE works fine on the Baseboard A with 4.15-rc6, but not on clusterboard, I also have an issue with MAC address assignment where the interface drops into monitor mode after a while...

hmm... sounds familiar...  
 
 
btw.. the like looks a bit messed up (looks quite that they wanna implement more reaction possibilities - I think we had this once before but disabled it?).

quote is also a mess.. the button shows up random somewhere on my browser..   --> maybe a 'opera only' feature?  
 
 
 
 

For what is worth, works great with my intentionally un-updated iPhone 6 iOS 9 
 
Edit: because... Old people are cranky!!! Get off my lawn slowing down my phone with new iOS, Apple!

First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU

True, I notice that USB3 port was not working. I was happy that it booted in the first place. I already merged into our main sunxi DEV branch (attached back to upstream master) and will try to remake this with a working USB3.

You need to be an expert to see this  Add EXPERT="yes" to the configuration.

Let's try it with an example and lock what happens/if it works...   Such a 'project manager' needs a background in the topic otherwise it's similar to marketing monkey writes product description for *random device*. I suggest we take @zador.blood.stained proposal as a test:
Is it possible to write a proposal what should be done out of it?
 
 
IMHO, it can't be a goal that you have to test all images on your own, otherwise armbian has to reduce the supported boards to much less boards. If you look into DL statistic, there are enough people downloading our images, there must be some interest from the community to report bugs (update or fresh download). Can we start with a 'testgroup lite'? IMHO most important (cause most annoying) is to avoid that the device is not bootable after update. As long as you have SSH access via ETH to the device, broken things can be fixed or at least, a backup of the data can made (I agree you should backup your system before the update - but to be honest, we have to accept that people don't do it). To avoid flooding the forum with a lot of junk from the testers group a small webservice might help:
With a clear statement that we don't suggest that you're test without having a serial console at hand (seems that a lot of user don't think it is necessary to have a usb serial device at home when playing with SBCs - maybe we should 'educate' our 'customers' also in this field....  ). 
 
Is it possible to have a 'board specific' update mechanism? E.g apt-update/upgrade only updates kernel/u-boot only if it's somehow on a 'positive list'? 
 
Internet of shitty Things is the 'new' buzzword...  Since people like @Larry Bank and @sgjava strongly push the GPIO issue, we might have a good solution in 2018.  To avoid  more load for the maintainers and keep Armbian as general as possible, I suggest to solve it similar to the OMV project. Means that we can provide a post installation script for a 'ArmbianIoT' but IMO we should avoid providing it in 'standard Armbian'.
 
A few questions:
Do we have a nightly desktop policy? Why do we provide desktop in nightly images? Does it make sense to provide such images as long as we can't provide 'basic stability'?

While they still don't cooperate with open source community as good as Rockchip, they at least are more cooperative. I asked for HDMI/DE2/DE3 documents and received all of them. Someone else asked about AC200 doc and also receive it. Or better said, they were uploaded to linux-sunxi.org. I would say that is a very good improvement.

beating a dead horse is not going to get you anywhere.
I rather support Amlogic or Rockchip

Right, why did you post to this topic while I had it open? I think I need to go check my network security now!   
 
Anyway, indeed... if this is node red and MQTT running, there is nothing to stop an ESP8266 with screen... say a 1.3" OLED or a 2.2" TFT, etc, from also polling the orange pi / etc and showing the data. 
 
 

and what does stop you of doing so ?

I finally gave up playing arround with the MySensors lib.  Main reasons are:
For every example they use predefined libs (DS18b20, DHT etc.) sometimes no support for updates of these libs.  Things like "This example uses a modified version of the external DTH library, which is included in the MySensors external examples." indicates to me, that this lib has some 'problems', otherwise this should work with the standard DHT lib.  The hole project seems a little bit predefined to me: Use the nodes we think you need, and since I'm not interessted in their nodes it does not make sense for me.  They presented so many examples of nodes, but I never found a example like: how to build your one node (for IoT stuff, where every one, including me, thinks that he would have a better idea how his node should look like, this is IMO the most important tutorial that you should have on your webpage).  I tried to get a DHT11/DS18b20 working on an arduino nano just to give you an example that this setup works, but I failed several times.  Since im not really interessted in the MySensors stuff anymore I would not waste my time for this. If someone tries it and it works, please add it to this thread, it would be cool for others which are interessted in the MySensors stuff!
 
@pfeerick the finally made it! (ok, not for the toilett, but would not be hard to adapt this..  )
 
Found on CNXSoft that  BLE is now able to implement mesh networking.  If this will be implemented on the cheap BLE modules (e.g. CC2541) this would be a game changer for IoT thingies... 

Yup, that's what it says at the bottom of the login banner...
 

armbian-config
 
Maybe...
 
Enviado desde mi Jolla mediante Tapatalk
 
 
 
 

I was informed about Armbian today, and so far from what I am reading it looks very promising.
I was on the Armbian configuration utility doc page:
https://docs.armbian.com/User-Guide_Armbian-Config/
 
But it says nothing on how to start it. whats the command for it ?
 

I've just tried to reproduce the problem with a 15cm cable... It still happens easily.
 
In my case, I don't think it's related with power supply but I'll try to clear that out in the lab.
 
If it was,  it should happen consistently with several USB devices overloading the power supply with the 4 CPU cores at 100% each, which never occurs.

I brought a TTL adaptor from my company's lab and now I can confirm I'm having precisely the same problem described in the OP.
 
I also found out this thread, which can be useful for other to better understand this issue: https://github.com/longsleep/build-pine64-image/issues/51
 
As I doubt I have a problem with the power supply I'm using, for now I decided to test another USB cable.
After that, I'll make proper testings of all the components involved if I need it...

I found one simple way, that helps me
I use armbian-config utiility, System -> Switch -> next
root@orangepipc:/media# uname -a Linux orangepipc 4.13.16-sunxi #20 SMP Fri Nov 24 19:50:07 CET 2017 armv7l armv7l armv7l GNU/Linux root@orangepipc:/media# mount -t cifs //192.168.1.5/D /media/share_test/ --verbose -o user=user,pass=verystrongpassword,vers=2.1 mount.cifs kernel mount options: ip=192.168.1.5,unc=\\192.168.1.5\D,vers=2.1,user=user,pass=******** root@orangepipc:/media# ll /media/share_test/ total 16196 /* List of files was ok */ Interesting moment: MAC address of ethernet card changed after change kernel