TonyMac32

Maybe, maybe not. If their CompaTability nonsense can simply be ignored, and the ARM cores are in control, then yes. If VC6 is running the show, it is the same. :-/

Sent from my Pixel using Tapatalk

The main thing for me is I wanted something more portable than RPi.GPIO, so that I can run  the same code on multiple SBCs without coding to a Pi specific API. Plus I wanted to cover the JVM in addition to Python 3 and C. Now I can pick what language makes sense in the context of the project instead of the API driving that (i.e. RPi.GPIO == Python only). Secondly, by using libgpiod for GPIO I'm insulating myself from all the low level coding and making GPIO portable.
 
To me it depends on the project. If I'm doing something from scratch (which I usually am) then I will gravitate to my library since I can port it to a different language or SBC easily. If something I'm working on has a RPi.GPIO or WiringPi dependency then I'll probably use those to save the effort and not reinvent the wheel. If I use luma.oled for instance then It's going to be a Python project. I can use Userspace IO's Python API for GPIO in addition to driving a OLED display with luma.oled.

you're the man. after compiling and installing 5.3rc1 boots out of the box

Me ...

I was able to read a DHT22 on PA10 with my Orange Pi Prime using https://github.com/Jeremie-C/OrangePi.GPIO
 
Minimal documentation provided in readme
 
https://github.com/lanefu/DHT22-Python-library-Orange-PI

Compressed 4K streaming content requires at most 25 Mbps, so this should be fine.  Uncompressed, well, that's a different animal.

USB-C power is very specific on how to design a circuit - too many folks take shortcuts....Looks like the Pi folks did as well...
 
https://medium.com/@leung.benson/how-to-design-a-proper-usb-c-power-sink-hint-not-the-way-raspberry-pi-4-did-it-f470d7a5910
 
Any competent EE will see the issue at hand...

The best option for today.
(I haven't seen the insides yet, but I hope to see them soon .   )
https://www.gearbest.com/tv-box/pp_009752605386.html?wid=1433363
 
Ideal for today (if you have the means\opportunity to buy it within 120-130)
Many different TV boxes passed through my hands. This model, in my opinion, is one of the best among TV boxes in terms of cost/result ratio. This is one of the rare models in which you do not need to finish anything yourself. It even universal multi-download will go directly to the firmware. This is a boring model, you will have nowhere to put your hands to improve and redo something.
 
https://www.gearbest.com/tv-box/pp_009954522026.html?wid=1433363
 
https://www.geekbuying.com/item/UGOOS-AM6-TV-BOX-Amlogic-S922X-2G-16G-2-4G-5G-WIFI-1000M-LAN-BlueBooth-417524.html
 
 

- 4 big cores on 28 nm, see the Tinker Board for a lesson in cooling that form factor.  (the Pi seems oddly underclocked, if I'm being honest, a 3288 will go 1.8 GHz, @wtarreau will tell you 2.0+)
 
- As far as USB3/Gb, the tunnel-vision Pi people would have seen an insane improvement with just 4x USB2 on their own channels and a 100 Mb PHY.  So yes, they are going to think they're lighting the world on fire performance wise.
 
- That USB-C does not appear to be intelligent PD type, so I'd be interested to see when people use smart supplies with it, if it will run on the 500 mA they'll probably limit to.  (correct me if I've gotten it mixed up)
 
It looks more interesting than the Pi 3, I bought a few 3's and have since let them rot.  I still used a 2 until recently for music.

Didn't know where to put this. Perhaps here  

- 4 big cores on 28 nm, see the Tinker Board for a lesson in cooling that form factor.  (the Pi seems oddly underclocked, if I'm being honest, a 3288 will go 1.8 GHz, @wtarreau will tell you 2.0+)
 
- As far as USB3/Gb, the tunnel-vision Pi people would have seen an insane improvement with just 4x USB2 on their own channels and a 100 Mb PHY.  So yes, they are going to think they're lighting the world on fire performance wise.
 
- That USB-C does not appear to be intelligent PD type, so I'd be interested to see when people use smart supplies with it, if it will run on the 500 mA they'll probably limit to.  (correct me if I've gotten it mixed up)
 
It looks more interesting than the Pi 3, I bought a few 3's and have since let them rot.  I still used a 2 until recently for music.

- 4 big cores on 28 nm, see the Tinker Board for a lesson in cooling that form factor.  (the Pi seems oddly underclocked, if I'm being honest, a 3288 will go 1.8 GHz, @wtarreau will tell you 2.0+)
 
- As far as USB3/Gb, the tunnel-vision Pi people would have seen an insane improvement with just 4x USB2 on their own channels and a 100 Mb PHY.  So yes, they are going to think they're lighting the world on fire performance wise.
 
- That USB-C does not appear to be intelligent PD type, so I'd be interested to see when people use smart supplies with it, if it will run on the 500 mA they'll probably limit to.  (correct me if I've gotten it mixed up)
 
It looks more interesting than the Pi 3, I bought a few 3's and have since let them rot.  I still used a 2 until recently for music.

- 4 big cores on 28 nm, see the Tinker Board for a lesson in cooling that form factor.  (the Pi seems oddly underclocked, if I'm being honest, a 3288 will go 1.8 GHz, @wtarreau will tell you 2.0+)
 
- As far as USB3/Gb, the tunnel-vision Pi people would have seen an insane improvement with just 4x USB2 on their own channels and a 100 Mb PHY.  So yes, they are going to think they're lighting the world on fire performance wise.
 
- That USB-C does not appear to be intelligent PD type, so I'd be interested to see when people use smart supplies with it, if it will run on the 500 mA they'll probably limit to.  (correct me if I've gotten it mixed up)
 
It looks more interesting than the Pi 3, I bought a few 3's and have since let them rot.  I still used a 2 until recently for music.

https://www.lifewire.com/wireshark-tutorial-4143298

Sort of.  it is still a Meson-GXL, think of it the same was as an Allwinner H2+ when compared to an Allwinner H3
 
I've heard there is no plan for proper bootloader support or EXT4 boot support, apparently Broadcom parts can't do what literally any other SoC is capable of from SPI flash...  So unfortunately I doubt Armbian will ever officially visit that board either...

Sort of.  it is still a Meson-GXL, think of it the same was as an Allwinner H2+ when compared to an Allwinner H3
 
I've heard there is no plan for proper bootloader support or EXT4 boot support, apparently Broadcom parts can't do what literally any other SoC is capable of from SPI flash...  So unfortunately I doubt Armbian will ever officially visit that board either...

Perhaps as an aid to our mutual understanding, would it be possible to link to a schematic and all released technical documents here, and provide an up to date image/layout of the board?  I see a few things on the Banana Pi site that are... awkward.  There are at least 2 revisions of the board on display with different port layouts, and the power jack next to the microUSB is labelled as "12 V"  is that accurate?  I don't know what that PMIC is off hand, so I'd be very unlikely to use that power jack unless you provided the adapter. 
 
I think there is potential, however I am an automotive engineer, everything document I make must be defensible in a court of law, so I am very specific and I require a lot of verified documentation. 
 
I am by no means looking for perfection, but it should be accurate enough that I can
Follow it without destroying the device Compile a generic linux without relying explicitly on your repo. Observe something near the advertised performance specs during empirical testing Identify all the right parts found in documentation. We need a thread where @Lion Wang @Nora Lee and @sean.wang are following and replying as is needed.  We are not asking any questions that should be unexpected, most vendors provide schematics and most vendors have reasonably accurate datasheets.  Our feedback should be very carefully considered, we are an educated user base, something development teams almost never have access to.  We have people that use these single board computers in industrial and other applications, when they say "It would be really great if..."  They know what they're talking about.
 
Now, I do not speak for the team, I only speak for myself and hopefully as a sane and intelligent individual:  My recommendation on getting Armbian support for boards is to come here, reach out to the Armbian community, and provide accurate and complete documents, ask us questions, listen to our answers, etc.
 
Lion_Wang, the figure you posted shows WiFi + BT as OK, but you say it isn't complete.  I see it's listed as AP6212 here, but on the R2 manual it says:  " banana pi BPI-R2 have support MTK6625L wifi&BT 4.1 chip onboard. "  <---  That is the sort of thing that causes trouble and upsets people.
 
The schematics are better than nothing, but they are scrubbed of IC names, values, etc, so really there is a limit to what value they are.  I do at least see +12V being specified there, and consistently through, so OK.  I was bracing myself for magic smoke everywhere...

the RPi isn't a board I look long enough to it.. Glue it together and hopefully you don't have to spend more time with it at all..
 
 

remember those dirt cheap android sticks you could buy years ago? The MK802.. I knew that I bought one years ago.. but didn't know for a long time that they're equipped with a AW A10... http://linux-sunxi.org/Rikomagic_mk802
 

 
Well, seems that they're supported in mainline (u-boot and kernel).
 
__ __ _ _____ ___ ____ | \/ | |/ ( _ ) / _ \___ \ | |\/| | ' // _ \| | | |__) | | | | | . \ (_) | |_| / __/ |_| |_|_|\_\___/ \___/_____| Welcome to Debian Stretch with Armbian Linux 5.1.7-sunxi System load: 2.26 1.12 0.43 Up time: 2 min Memory usage: 4 % of 999MB IP: CPU temp: 11°C Usage of /: 4% of 30G ... root@mk802:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 21:44:11: 1008MHz 1.57 82% 30% 20% 0% 30% 0% 11.6°C 21:44:16: 1008MHz 1.68 19% 19% 0% 0% 0% 0% 10.9°C 21:44:21: 1008MHz 1.55 13% 13% 0% 0% 0% 0% 11.4°C 21:44:27: 1008MHz 1.42 22% 21% 0% 0% 0% 0% 11.2°C 21:44:32: 1008MHz 1.31 17% 14% 1% 0% 0% 0% 11.6°C 21:44:37: 1008MHz 1.20 21% 20% 0% 0% 0% 0% 11.0°C 21:44:43: 1008MHz 1.11 13% 13% 0% 0% 0% 0% 8.5°C well the thermal is a bit sloppy.. in fact the SoC was roughly 60°C at this time...
 
and soldering UART to test points isn't as fun.. but it works
 
and now imagine this board with sata instead of HDMI wired out.. (well maybe with the A20 instead of A10)..

That is NOT how I want to die.

I'm not sure what will and won't be a worthy overlay to put directly into Armbian itself with the current script structure, I intend to document the ones I add here, @martinayotte may as well if he's bored.  :-P
 
I will be focusing on RPi GPIO compatibles, since those are nice pre-packaged devices in general.  I have Tinker, RockPi 4, Le Potato/K2/C2, Tritium H2+/3/5, Rock64, Renegade, and some others.
 
Everything here is a placeholder at the moment.
 
Status   Tinker Le Potato Meson64 Renegade Tritium Automation Hat           Generic DAC (Pi)           MCC 118 DAQ           MicroDot PHAT           Inky WHAT (e-ink)           ENC28J60 for Pi                                                

I agree, which is why this is not under normal development as a topic.  There is the reality, however, that people buying RPi-shaped boards want support for RPi peripherals and accessories, so my thought is to discuss ways to support that, while implementing a few on a platform that only has 1 board with gpio anyway (Rockchip).  If it must be that I have a fork of the build system and stuff all of this in "user patches" then so be it, but I think we need to come up with a way to handle this per board rather than per family.

An RPi is not

1) reliable
2) the most cost-effective
3) worth $35
4) worth any more discussion.

The position of this project stands, we will not support a failure prone, insecure, underperforming, inefficient, abysmally bandwidth throttled device. If an RPi 4 comes out that uses a sane bootloader and a useful SoC then this can be revisited.

Do not continue your personal argument with Tido; it is not value-added, and your positions add nothing other than conflict. Mostly because you have no facts or reason for your position, and instead of trying to formulate something approaching a case for support resort to ad hominem attacks and downright inaccuracies. This is an unofficial warning to stop harassing the team because you aren't getting your way. The next will be official.

Sent from my Pixel using Tapatalk

An RPi is not

1) reliable
2) the most cost-effective
3) worth $35
4) worth any more discussion.

The position of this project stands, we will not support a failure prone, insecure, underperforming, inefficient, abysmally bandwidth throttled device. If an RPi 4 comes out that uses a sane bootloader and a useful SoC then this can be revisited.

Do not continue your personal argument with Tido; it is not value-added, and your positions add nothing other than conflict. Mostly because you have no facts or reason for your position, and instead of trying to formulate something approaching a case for support resort to ad hominem attacks and downright inaccuracies. This is an unofficial warning to stop harassing the team because you aren't getting your way. The next will be official.

Sent from my Pixel using Tapatalk