Werner

Thank you very much @martinayotte !

It works like a charm! We're able to communicate with an external device.

We will try and see what's going on in the sun4i-i2s driver.

Again great job martinayotte, thank you!

Edit: Donated a little bit of money, it would be nice that others looking for help would do the same.

well Let's try it in a 'markdown' way, where #category ## forum ###subforum.
 
#Announcements & first aid
   ## Annoucements (e.g. someone steps back, someone gets maintainership, new major release - only certain people can post here)
   ## Board doesn't boot
      ### Hall of Shame aka SD-Card and PSU related issues
#Bugtracker/ Armbian related issues
   ## Allwinner A20
   ## Allwinner H2 & H3
   ## Allwinner H5 & A64
   ## [WIP] Allwinner H6
   ## Armada A388, A3700
   ## Amlogic S905(x)
   ## NXP (Freescale)
   ## Rockchip 3288 & 3328
   ## [WIP] Rockchip 3399
   ## Other supported boards
 
#Community forums
   ## P2P tech support
      ### Debian/Ubuntu or general Linux related issues
      ### Hardware Hacks
      ### Unsupported boards
   ## From users for users
      ### Reviews
      ### Research guides and tutorials
   ## TV boxes
   ## Chitchat
   ## trash
# Development
   ## Board bring up
   ## Armbian build framework
   ## Features development (here should stuff be discussed which we want to fix/rewrite e.g. when nand-sata-install gets reworked etc.)
 
 
development is then only a small part (but probably not in subforum after subfroum).. for development of armbian or it's buildscript.. the SoC related development threads will move into a bug-tracker since it doesn't matter if it's a bug for a supported platform or not.. we want it fixed in the end.. the wip marked forums will just have a polite remember what wip means.. Maybe we could kill all subforums to have it more clear..

Unlikely. It's a problem with their kernel. We don't use Debian kernel - it's way too old, but I will pay attentions to upstream changes in this area. 

I got the things working !
Although I didn't tested it with real SPI device, I've at least tested it with loopback wire between MISO/MOSI and executed spidev_test ...
https://github.com/armbian/build/commit/34205e60b3efa0ef3acc293ed9e02b801f8a52c1
 

Which boards?

as give away .... for developing  ... to support the ARMBIAN Project
 
;-)
 
Have fun! 
Feel free to contact me:
   post@humberg.de

Do you mean you have some spares to give away ?
Maybe I could be interested ...

Hello community,
 
I got some brand new Pine H64 Model B this week.
Anyone interested in a free test device?
 
Markus

There are a few differences between both boards. It's like saying that an Audi car is the same as a BMW because they have the same engine(I know nothing about cars).

I've got the PineH64 model B here, but I don't have a complete overview of the specs yet.
What I can say is OPi has LPDDR3 ram up to 2GB, while the PINE H64 has got LPDDR4 up to 3GB.
The OPi has got room for a smd eMMC module, while the Pine has got a eMMC socket so you can remove it.
The OPi has got 4xUSB3.0 ports while the Pine64 only has one USB3 + 2 USB2 ports. I don't know if there is only on USB3 root hub or multiple. So could be that the 4xUSB3 on the OPi are just over the same hub what makes both OPi/Pine as fast.
The Opi also has got USB2.0. The Pine H64 is a lot more compact.
 
It is way too early to say if these boards will have good support for everything you want. You'd be better buy something that's know to have all that instead of one of these. It will take months, and it is to see how many people want to develop for it.
For now all I have is a very badly working Android image, and a Armbian Bionic that only works when I dissable all networking. But that's not very useful at all. It is a very nice board tho. 9/10 for looks
The OPi is also on the way, should have been here a while ago. But they didn't send before Chinese Newyear, so only this week it's departed. Great I've got the PineH64 now. (thank you @Humberg )

Proposed actions:
 
1. Renaming section "Technical support" to "Bug tracker" (leave restrictions as is)
2. Merging "Common issues" with "Peer to peer" and place under "Community forums" section
3. Creating new section "First aid" 
    - move "SD card and power supply"
    - create "Board doesn't boot"    
    
    or move "SD card and power supply" one level up and rename to "Board doesn't boot"    
 
Alternatively:
4. Make "armbianmonitor -u" field mandatory for "Bug tracker" section except "board doesn't boot"
5. Move NXP and Armada A388/A3700 under "Other supported boards"

3.10.65 on OPi 3? Armbian will never deal with the BSP kernel for H6 boards, you may ask in Xunlongs supportforum.
 
 
it would be worth to have your buildscript and it's changes (as a fork) on your github as well, so that people interested in your work can see what you tried so far or even contribute to it.

https://pi-hole.net/2019/02/03/pi-hole-v4-2-available-with-shared-memory-new-blocking-modes-and-more/
 
v4.2.1 Hotfix
We have released a small hotfix which addresses possible crashes experienced for users without libcap capabilities
(running FTLDNS under root). For most users, this update will not change anything.
 
HIGHLIGHTS
 
New Blocking Mode
We’ve added a new blocking mode (NODATA), where blocked requested are replied with a status code of NOERROR
and A / AAAA records are empty.  
It’s unclear if there are advantages to this mode over others, but you’re welcome to experiment with it.
 
Shared Memory
In preparation of the new API we are working on, FTLDNS will now store its data in a shared-memory space,
so that the API can come in and read from that memory to fulfill requests.  
In short, this means FTLDNS will be even lighter as it doesn’t have to care about sending the statistics to some requester.  
Instead, it will concentrate on generating the statistics and the API can read FTL’s data directly,
resulting in reduced delays in the API.
 
wpad Vulnerability Fix
We previously mentioned how you could work around a vulnerability regarding wpad entries.  
This fix is now in place as suggested by dnsmaq.conf.example.
 
Fixes And Tweaks
We updated SQLite to 3.26.0
We fixed the query status if a forwarded query was partially replied to from the cache
We now prevent multiple static DHCP entries with same IP
And more…
 
Docker Version Also Updated
We heard your feedback and we made sure to coordinate better to release our traditional install and our Docker install together.
The docker image will be released when testing is complete.

I have a dedicated KVM image, as I don't want to introduce changes from the distribution that might impact the build process - it's an old habit of mine.
 
Anyways - root is a major deity on a *nix system, and an errant script could do a fair amount of damage - it doesn't have to be a "bad actor" but even a typo...
 
Started looking at fakeroot as an option, as this does provide the opportunity to do file manipulation as needed to build an image.
 

By default yes, but it is possible to tune-up (at least KVM) to run almost at the same speed.

Changes were applied also to the stable repository. No need to switch anywhere. I guess all mirrors have also been updated by now.

Agreed.
 
I think the logs are a good call,  if we have SoC sub forums in "community forums" we can allow more or less anything appropriate.

If it helps anyone,  I've been running succesfully with gigabit ethernet on eth0 using the dts and h6 dtsi from Icenowy's
 aosc-sunxi64-4.19-malimidgard-hack-2
 
branch and the armbian dev kernel .    I force a stable mac_address by adding  
allow-hotplug  eth0 
iface eth0 inet dhcp
    hwaddress ether xx:xx:xx:xx:xx:xx  (replace the xx's of course with a good address)
 
in the /etc/network/interfaces  file.  
 
I haven't yet been able to get spi-jedec-nor  flashed to enable sdi boot,  I get an error indicating that there is a mismatch between what is specified in the DTS vs the overlay, but I am booting off of an sd card with the file system on a usb connected ssd.
I'm going to try to build with the mainline 5 kernel soon,  to see If I can pick up the new graphics drivers...
 
I believe version B of the device is supposed to be out soon...

Thankyou so much for all your comments and help. I honestly did do my reading, but not what has been pointed out. So I stuffed up. 
 
I rebuilt using bionic before reading the last of those comments, but its up and running so Ill see how it goes.
 
The first thing I notice is the CPU is running at 47c instead of 57-60.c I also changed IP address and it instantly changed it without reboot. Two big differences already.
 
In trawling the logs I did notice some DNS messages. Now they make sense. So it looks like pihole was having problems with Jessie as well, just like you point out. 
 
So all up, although its only been running for an hour or so its already looking better.
 
Thankyou very much for the help. And hopefully I wont be back on this thread !!

https://github.com/armbian/documentation/commit/9d43fb8b2baf45258b5ef84dafc31585889cfc70

In case you want to squeeze in something. DUE: Sunday.

Yes. Or Debian with the same kernel. Depends on your taste  
As for myself I prefer Debian as the directly by Debian maintained packages count is way higher than by Ubuntu.
Lots of packages on Ubuntu are Universe or Multiverse which means there is no guarantee for support or (even critical) fixes.

Since the last year (and around v3.3 of pihole) it isnt recommend to use pihole with debian jessie anymore:
https://pi-hole.net/2018/02/14/pi-hole-v3-3-released-its-extra-special/

So pihole will run much smoother with debian strech (or Ubuntu bionic).

That is a lot of traffic but you don't have to host the downloads, that's why I said necessarily. You can use sourceforge to host all the files, and you currently use torrents which is smart.
 
Thank you for sharing the information, it is interesting to see.
 

 
I didn't realize there was so much traffic but file hosting can be had for free being Armbian is open source. I was strictly speaking of the website when I said 100/month.
 
I think hosting fees is very relevant since that money can be used elsewhere, especially since it seems like it must be expensive currently.
 

I think that was never the intention that 'armbian people' only answer to questions.. fist cause there are for sure other smart(er) people here and their contributions are highly appreciated.
Personally I wouldn't participate in such an sub-forum. But I don't spend as much time in armbian when my 'dayjob' doesn't allow it. By paying for support people expect solutions, solutions aren't that easy. If *random hardware feature* doesn't work the pressure should be on the boardvendors side to fix it not on ours. For maintainers spending much more time to keep the project running (e.g. Igor) some sort of a salary might be mandatory and ways to make this possible isn't as easy but I don't think that such a payed supportforum is the way to go.
how about a less radical approach. Just ignore topics which don't provide the needed information? Those really interested in getting their issue heard/solved may get it that there's information missing.
 
challenge accepted. (we shouldn't lose our sense of humor even if it's a dark one )
 
Besides that, I'm fine with stupid questions. Even in the field I'm good in (chemistry) I sometimes have stupid questions.. Happens.. but the way you react when you realize that you asked a stupid question makes the difference.. If you start to complain about support and and come up with "but the users are most important" I'll answer you with a polite form of "Go fu... *have sex with yourself*"... If you look at a forum from an SBC armbian doesn't support you'll see that moderators there have some sort of a scheme for questions they don't want to answer - always ends with: believe us we sold 20 millions boards we know what we're doing..
We've to accept that there are people on forums which don't spend as much time on SBCs to get trivial issues solved on the other side, they've to accept that if they're not willing to invest time to fix things on their own/help us figuring out what's wrong, I'm not willing to waste my time with their issues.
 
 
The first iteration of the new mandatory parts for opening a topic in technical support was a failure:
 
the new version with:
is at least not as harsh anymore.. but as @zador.blood.stained and @martinayotte showed  (https://forum.armbian.com/topic/9400-does-not-see-emmc-after-component-change/) here, there's still room for improvement. Maybe it needs some days/weeks/months until we have a solution which is "more or less" satisfying but I still think setting some pressure to people to provide armbianmonitor in their starter isn't a bad thing. Cause it is annoying to ask always for it and hope that he gets it after you asked for it 10 times..  (and it's also annoying to find different polite forms of the part from the "personal non rational rant" )
 
For me this thread should be merged with "Improve 'Support over Forum' situation" - IMO it belongs to it. If nobody disagrees on that let's move it there.

Yes. In the early days, about linux 4.17 when the first initial support for Allwinner H6 from Armbian came, it was limited to 1,5GHz but I remember a patch for 4.18 which rised the max frequency to 1810MHz and it ran well. I did benchmark without cooling whatsoever and it survived. Over a longer period of time on heavy load I would think about some kind a cooling though,

I guess this speaks for yourself...