chwe

/etc/armbian-image-release and /etc/armbian-release are different files and have a different purpose. The former was added to track the source image version in case of upgrades, kernel switches, etc., it won't be present on many older images so it shouldn't be used for platform identification.

Interesting, I'll have a look at it this when I'm back at home (tested it on 3.4.113 Kernel weeks ago).  Would be nice to see a copy of the error but I'll try to reproduce your error (I've a OPi0).
 
The whole project started cause I wanted a lib which works without changing code between my OPi0s and my OPi+PC. Setup.py will have a cleanup in the future. 

The pyA20 gpio library is quite famous when people start to play with gpios , spi or i2c on sunxi boards but mapping needs often adjustments to work on your own board. This situation is not really friendly for 'beginners'.  pyGPIO should help to make armbian a little bit more 'IoT friendly'. 
I didn't touch the 'backbone' of pyA20, so the syntax should be similar to its original (except pinname when using port instead of connector). 
 
How can I use this library:
Cause all of this boards have (more or less) the same pinheader (sometimes other pins are deployed on the pinheader) pyGPIO tries to unify the mappings, so that code can be shared and deployed on all boards without touching the code. The mapping follows the pin naming of the RaspberryPi (it's not because I think their naming is perfect, but it should be the easiest way to port code from the 'RPi world' to Armbian.

What is done:
-Initial support for:
OrangePi Zero/PcPlus/Lite/Plus2E NanoPi Duo(with and without Minishield)/Neo Olimex Lime/Lime2/Micro (pins are not renamed PG10,PG11 etc. instead of GPIO2, GPIO3 etc. cause those boards doesn't have a 'RPi Pinheader' Templates for 24,26 and 40 'RPi compatible' pin header -Board detection (when using Armbian) to check if your board is supported
-Manual assignment when your board is not supported (yet) or automatic board detection fails
 
What is not done:
Testing testing testing! Documentation Meaningful examples (still the originals from olimex which wouldn't work anymore)  
What do you need to test the Library:
You need python-dev and the Library which you'll find on my GitHub page. The installation should be easy, just follow the instructions... 
sudo apt-get install python-dev git clone https://github.com/chwe17/pyGPIO.git cd pyGPIO sudo python setup.py install  
Testing is the part where I need help. I don't have most of the boards which are supported (only OPi0 and OPi Pc Plus). I tested I2C and GPIO on the OPi0, for all the rest, I need you as testers, bug hunters, and feedback.
 
Here are two short python snippets which should do the exact same thing (once with connector, you have to run them as root or with sudo otherwise it would not work!):
import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, connector from time import sleep gpio.init() gpio.setcfg(connector.GPIOp7, 1) #pin 7 as output n = 0 while n < 5: gpio.output(connector.GPIOp7, 1) sleep(1) gpio.output(connector.GPIOp7, 0) sleep(1) n +=1 sys.exit('finished ;-)') and once with port:
import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, port from time import sleep gpio.init() gpio.setcfg(port.GPIO4, 1) #gpio4 as output n = 0 while n < 5: gpio.output(port.GPIO4, 1) sleep(1) gpio.output(port.GPIO4, 0) sleep(1) n +=1 sys.exit('finished ;-)') Annotation: When using NanoPi Duo you've to possibilities with or without Minishield. Pin name is the same on both possibilities but when using port but pin numbering when using connector:
Minishield: 3.3V |1·| 5V GPIO2 I2C0_SDA |3·| 5V GPIO3 I2C_SCL |5·| GND GPIO4 |··| GPIO14 UART1_TX GND |··| GPIO15 UART1_RX GPIO17 SPI1_MOSI |··| GPIO18 GPIO27 SPI1_MISO |··| GND GPIO22 SPI1_CLK |··| GPIO23 SPI1_CS 3.3V |··| NC (on mini shield) Without (e.g. connector.J1p7 or connector.J2p5) : J1 J2 (UART0_RX) |1| microUSB |1| 5V (UART0_TX) |2| |·| 5V GND |3| |·| 3.3V GPIO3 (TWI_SCL) |4| |·| GND GPIO2 (TWI_SDA) |5| |·| GPIO4 (IR_RX) GPIO23 (SPI1_CS) |6| |·| GPIO18 (IOG11) GPIO22 (SPI1_CLK) |7| |·| DM3 D- GPIO27 (SPI1_MISO) |·| |·| DM3 D+ GPIO17 (SPI1_MOSI) |·| |·| DM2 D- GPIO15(UART1_RX) |·| |·| DM2 D+ GPIO14 (UART1_TX) |·| |·| RDN (CVBS) |·| |·| RDP (LINEOUT_L) |·| |·| TXN (LINEOUT_R) |·| |·| TXP (MICP) |·| |·| LED-LINK (MICN) |·| microSD |·| LED-SPD Buttons (bigger orange pi boards) are mapped, but I didn't test if it works (mapping here, if somebody is interested in testing them, see mapping.h of your board):
 
{"BUTTON", { { "BUTTON", SUNXI_GPL(4), 1 }, { { 0, 0, 0} }, } },  

I had a meeting today and all except last two posts, since not existing at the time, were checked. In general, I was more or less presentation our pain with existing ideas how to solve this and that. Wordpress stays since they are familiar and since the problem is not there. Data will go into temp database (from GitHub config files as it comes now) that any possible search/filtering is possible, used or not. UX redesign has top priority than graphics tuneup and then backstage improvements. Estimated due ... hardly this year. Rather slow and good.
 
Now waiting for the first prototype, then arguing further.

It might help if the people know which library you use to trigger the GPIOs... 

Shouldn't this be possible with the OTG Port by toggling PL2?
 
Edit: But restart isn't really a nice approach to solve your issue not?
 

And this works surprisingly VERY WELL. My Orange Pi powering a Banana Pi (since there we can measure voltage):
 

 
The Orange Pi is powered through Xunlong's 5V/3A PSU. And this is how it looks wrt voltage on the Banana Pi (the white cable in between is an 20AWG rated MicroUSB cable):
### Current system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 11:38:12: 960MHz 0.18 10% 6% 2% 0% 2% 0% 48.9°C 30.1°C 5.14V 0/6 11:38:13: 960MHz 0.18 17% 15% 2% 0% 0% 0% 48.7°C 29.9°C 5.12V 0/6 11:38:14: 960MHz 0.18 25% 20% 1% 0% 3% 0% 48.4°C 29.7°C 5.15V 0/6 11:38:15: 960MHz 0.18 10% 8% 2% 0% 0% 0% 48.4°C 30.0°C 5.16V 0/6 11:38:16: 528MHz 0.18 22% 19% 2% 0% 0% 0% 48.2°C 29.9°C 5.15V 0/6 11:38:18: 960MHz 0.32 10% 6% 2% 0% 1% 0% 49.4°C 30.7°C 5.07V 0/6 11:38:20: 960MHz 0.32 100% 7% 92% 0% 0% 0% 50.3°C 31.0°C 5.10V 0/6 11:38:21: 960MHz 0.32 75% 7% 68% 0% 0% 0% 49.1°C 30.2°C 5.15V 0/6 11:38:23: 960MHz 0.38 16% 11% 0% 0% 4% 0% 49.0°C 30.0°C 5.16V 0/6 11:38:24: 528MHz 0.38 11% 10% 1% 0% 0% 0% 48.6°C 30.2°C 5.10V 0/6 Starting at 11:38:18 a short stress test had been started in the background. Voltage still at 5.07V which is just... great.
 
Adding a host powered SSD to Banana Pi of course led to an instant poweroff. But on the Orange Pi it was just a simple CLI command to get the Banana restarted (without SSD connected of course!):
echo 0 > /sys/class/gpio/gpio354/value ; sleep 2 ; echo 1 > /sys/class/gpio/gpio354/value  

This thread gets a bit out of control...  So let's see if we bring this thread a bit more productive.
 
You explained now at minimum two times that you can't provide sudo armbianmonitor -u from your first build cause you didn't have this image anymore.  But since the 'stable' build you use still crashes, you could provide it for this build? 
Printscreens are the last chance when armbianmonitor isn't possible at all (board doesn't boot or upload fails for whatever reason).  As @tkaiser pointed out here ,  he as an experienced SBC user gets much more Information from armbianmonitor than from printscreens.
 
A reminder back for you (you should see before your first post):
 
He might be a little bit harsh but when he several times ask for something and you deliver everything else but not the things he wants he might be a bit annoyed. Others would stop answering your question cause they thought it's a 'waste of time'... 
My personal opinion: It's up to you. If you can't deal with 'harsh' answers, solve it by your self or hope that somebody else joins this thread to help you. But @tkaiser knows those SBCs best better than most of us for server use cases (not that I wanna upset others) and it might be a good idea to follow his advice. 
 

After latest commit on those crappy Bananas and other A20 boards a little bit more underpowering monitoring should be possible when our next major release is out soon. Example output (from a Lime2 with a dying PSU and only protected by a huge battery and AXP209 PMIC any more):
 
### Current system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 21:57:46: 720MHz 0.33 4% 1% 1% 0% 0% 0% 39.6°C 40.3°C 4.44V 0/6 21:57:47: 528MHz 0.33 17% 13% 3% 0% 0% 0% 39.6°C 40.0°C 4.44V 0/6 21:57:47: 528MHz 0.33 18% 13% 5% 0% 0% 0% 39.6°C 40.1°C 4.44V 0/6 21:57:48: 528MHz 0.33 17% 14% 2% 0% 0% 0% 39.3°C 40.1°C 4.34V 0/6 21:57:49: 528MHz 0.33 29% 23% 2% 2% 0% 0% 39.3°C 40.1°C 4.44V 0/6 21:57:50: 960MHz 0.54 4% 1% 1% 0% 0% 0% 39.4°C 41.1°C 4.19V 0/6 21:57:51: 960MHz 0.54 100% 0% 100% 0% 0% 0% 39.4°C 41.9°C 4.19V 0/6 21:57:52: 960MHz 0.54 100% 1% 98% 0% 0% 0% 40.3°C 42.1°C 4.19V 0/6 21:57:53: 960MHz 0.54 94% 2% 92% 0% 0% 0% 40.3°C 41.6°C 4.42V 0/6 21:57:53: 528MHz 0.54 17% 14% 2% 0% 0% 0% 40.3°C 40.8°C 4.41V 0/6 The first 5 lines should show normal/idle behaviour while then a 'stress' task is fired up (as many threads in parallel as CPU cores available) which should show voltage drops on boards with insufficient power cables and PSUs (applies especially to those Micro USB equipped boards but of course can also show PSUs making problems as above -- without battery I would assume this Lime2 would be dead already since a long time)

http://www.x-powers.com/en.php/Info/product_list/cat_id/31
 
The AXP8036 seems a lot like the Realtek USB audio on the Tinker Board, it doesn't exist.  ;-)  (I assume it physically does, but datasheets seem impossible)
 
Does not look like there is any hope for voltage scaling however, that is a fixed regulator.
 
Hmmm...

 
Is this supposed to go back to VDD-CPUFB on the SoC?  That would be my guess, otherwise why not tie them together?
 
There are fuses on a lot of boards, the RPi's, Le Potato, the Khadas VIM, it is one of the hazards of bypassing the factory connector (even if it is u-USB).  They're always self-resetting thermal polyfuses, although it's always extremely important to understand how long it takes one of those things to "blow".  for instance, if that's a 2 Amp "hold" fuse like the Littlefuse 1812L series, it will take 8 amps a maximum of 2 seconds to make it go fully open.  In that example it also has a series resistance of 20 to 70 m-ohms. 
 
I don't see a header for DC-in, but that's not surprising.
 

All unused GPIOs are defaulted as normal GPIO, no needs to tweak DT.
And they can be tested easily using /sys/class/gpio ...
 

Any reason you're not using 4.13?  4.14 is still a Dev release, it's not fully patched.

it's everything there...  just open your eyes... 
 
And I don't use it, I was only interested in the script.bin file... It boots,  wifi 'works' but without an external antenna, it's not stable in an urban environment. 

I'm currently working on a fork of the pyA20 python library which is used quite often by people here when playing with GPIO, spi or i2c. It's not ready for public at the moment, but it will be soon.  It has an automated board detection, pin naming is consistent so that you can use your python scripts on every supported board without renaming everything. And it has a 'board detection' mechanism to use the right pin mapping during the installation. 

Fixed.

P.S. my friend purchased an OPi R1 and I may help him to make it mainlined ;-)

But BPi-M2+ has 'no voltage regulation' for CPU.

Which makes it 'not useful'.  Maybe you can fix this issue (and make an annotation in your documentation for this board) when you produce the next batch of this board?

1. No (4 non shared USB ports + separate LAN)
2.  No idea,  not the fields I'm interested in...  (personal opinion H2+, H3 SBCs aren't best for multimedia purposes, but this just an opinion)
3. No (4 non shared USB ports + separate LAN)
4. No (it's also called CSI, but not the same)
 
Edit: When you consider using mainline:
No camera support at the moment (to my knowledge) No hardware accelerated video decoding

We have a search function (in the upper right of this web site, eg. enter tvheadend there if you need information about tvheadend), we have some documentation, we have device pages like this where you should click on 'hardware details' that should be able to answer all those questions.
 
If you expect Orange Pis to be 100% compatible to Raspberry Pis then better stay with what you have now. Also due to this here being a way smaller community you'll need to help yourself a bit to succeed (use the search function for example).

Mikey should think about this lines too:
[uart3] uart_used = 1 uart_port = 3 uart_type = 2 uart_tx = port:PA13<3><1><default><default> uart_rx = port:PA14<3><1><default><default> uart_rts = port:PA15<3><1><default><default> uart_cts = port:PA16<3><1><default><default> From your schematics, PA15 & PA16 are expanded on 'CON 2' header, so it would be no problem to use it (uart_type = 4).
 
Further (line 790 to 793):
[s_rsb0] s_rsb_used = 1 s_rsb_sck = port:PL00<2><1><2><default> s_rsb_sda = port:PL01<2><1><2><default> half of this bus is now used for switching between 1.1V & 1.3V so s_rsb_used = 0 cause you can't use it for other porpuses.  
 
Maybe if you want to improve things, Mikey  could also set a 1 (w1_used) here:
[w1_para] w1_used = 0 gpio = 10 gpio = 10 means that one-wire would be available on (PA10, means PIN35 on your expansion header) or to make it even easier for the users set 'gpio = 20' (PA20) which would than be the nice PIN40 on this header. But you have to inform your users that they should set CPU min freq to 480MHz (otherwise your Forum would be full of stuff like 'why's one wire disappearing constantly?' ). This might be something for your gitbook pages. Explaining the users 'how to connect something like DS18b20 to my BPi M2 Zero'
 
 

https://docs.armbian.com/Developer-Guide_Build-Preparation/
 

I downloaded your image from your google drive yesterday (btw google drive is an awful storage place when you've to download large files from a console, but this small python tool helps a lot).  I mounted the fat partition and extracted script.bin from /bananapi/bpi-m2z/script.bin. A quick look at it wasn't that exciting.
 
3. line:
machine = "Banana Pi BPI-M2-Plus" false board name as Thomas said on one of his first posts in this thread (July 30). 
 
183 - 190:
[uart3] uart_used = 1 uart_port = 3 uart_type = 2 uart_tx = port:PA13<3><1><default><default> uart_rx = port:PA14<3><1><default><default> uart_rts = port:PA15<3><1><default><default> uart_cts = port:PA16<3><1><default><default> defined as uart_type 2 but rts and cts are defined. 
 
start at line 739:
[dvfs_table] pmuic_type = 0 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 11300 pmu_level1 = 1100 max_freq = 1200000000 min_freq = 240000000 LV_count = 6 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 1008000000 LV2_volt = 1300 LV3_freq = 912000000 LV3_volt = 1100 LV4_freq = 648000000 LV4_volt = 1100 LV5_freq = 480000000 LV5_volt = 1100 LV6_freq = 240000000 LV6_volt = 1100  
The only place where people see that it should be PL01 instead of PL06 is your schematics and armbians forum. 
 
If you still asking yourself why Thomas is attacking constantly your company, this might be a valid reason. Besides playing with SBCs I'm doing in science where we have a peer review process for everything we publish.  As a peer reviewer, I would reject your 'script.bin paper' with a short comment that you should do your homework first before I have a more detailed look at it. 
 
FYI: I didn't check everything in the script.bin and I'll not do it until you showed that things are improving. 
BTW: PL06 is used as USB0-id, I've no clue what happens when this pin goes from high to low (or vice versa) every time the CPU clocks up if you have a USB device connected to this port...  (EDIT: https://www.maximintegrated.com/en/app-notes/index.mvp/id/1822 could be interesting if you use USB as OTG with changing roles... )

It's not about last chance, I think you missed a key point there.  Support for a new board is mostly a question of time and knowledge of an experienced developer taking care of a SBC.  When you've a look which BPi boards are supported with a 'stable' armbian. You could see that there are a few of there boards:
BPi M2+ (H3) BPi M2 (A31s)
BPi Pro (A20, actually a lemaker, not SinoVoip product, correct me if I'm wrong here...)
BPi + (I think this is called M1+ by SinoVoip, also a A20)
BPi (should be the one called M1 by SinoVoip, A20)
 
IMO, the reason why you see so much more OPi boards supported by Armbian is the following: They have a real conservative 'board design philosophy' - more or less every board from xunlong is based on H2+/H3 which as Thomas said, makes it easy to add support (as long as you've correct schematics, or as xunlong does it 'never change a winning team' - you know one, you know most OPIs ).  SinoVoips approach to invent '20 different wheels for 15 use cases' (means having a bunch of different SoCs on their SBCs,  and therefore many different board designs make it harder to support their boards).  
 
I bought a BPi Zero (and paid the full price  ) and I'm sure that I'll have a dedicated armbian running on it (I think I'm able to adjust the basic things I need to get my needs running if nobody from the 'core developers' are willing to do it) but I'm not able and passionate enough to be a 'maintainer' like @TonyMac32 for the tinkerboard (actually a board which has also a lot of design flaws ). Means I'll not spend much time on things I'm not interested in and I don't feel responsible to answer every question about it on the armbian forum.  Naming your images Raspian (something Xunlong and SinoVoip do) is IMO false advertising. First their boards are not RPIs. Second, Raspian is built on a (more or less) recent kernel (at least 4.x). Third, GPIO libraries  are working out of the box (which is often not true for these boards) and last, things like mathematica,  Node-Red & Wolfram Alpha works also out of the box (I never checked all these things on the OPis or BPis Raspians, but for the kernel it's sure - most OPis running the outdated 3.4.39 kernel BPi0 improved here slightly with a 3.4.113 kernel). Both companies don't shine on software support (but Xunglongs 'conservative design strategy' makes it easier to support their boards), so improvement there would be really appreciated.
 
Annotation: this part of my post has some sort of humor, sarcasm & frustration in it, if you can't deal with it, just don't read it.  
A basic 'board bring up' for an H2+/H3 board (as repeated a way to often in this thread  ) is not a huge deal. But maintaining the community support clearly is (just have a look here how many questions come up for *random SBC*). More or less every week a thread 'why wifi on OPi0 does not work?' (shitty XR819 just use search engine) or 'why armbian does not support RPi display on tinkerboard?' (armbian is not the board maker, this is a spare time 'job' we don't have time to do everything in minutes,  btw. congrats to @tonymac32, you got it work! I think we're now close to ASUS advertised RPi compatibility with the tinker ).  So, the more boards armbian supports, the more time experienced supporters of armbian are absorbed by answering this questions, testing images etc. (Thomas would say, 'waisting time'  ).  And what's also clear,  the more a board is claimed to be raspberry compatible, the more 'inexperienced users' joining armbian (best example Tinkerboard).  This might avoid someone like Thomas being excited adding support for such a board cause he knows the consequences - more 'inexperienced users' (sometimes too ignorant following basic instructions from an experienced armbian supporter -  see here for some examples), expecting that everything on armbian should work similar than on raspian cause boardmaker claimed RPi compatibility and armbian is based on debian. So, 'no difference to *random RPi*'  (except, it has to be cheaper than a RPi and I want 'real SATA' on my board).  That's why I still like the RPi - more or less everything they advertise works on their boards. It's not the most powerful board (you get more powerful & cheaper SBCs on an H2+/H3 basis) but most things the *average SBC user* can imagine is solved by someone from the RPi world and they've targeted the 'noob problems' (it's a shame that they still use the micro USB connector for the RPi3 but nevertheless they have a 'protection mechanism' to avoid underpowering the board - one major issue on cheap H2+/H3 boards here at armbian). 
I hope you see the point in all this *random BS I talk here*
Board bring up would be easy Support needs a lot of time more *average RPi users* means more ignorant users (not all of them, but part of them are) the more a bord is claimed to be 'RPi compatible' the more *average RPi users* will show up here - the more time is needed to explain to them that verdor claimed RPi compatibility doesn't mean that this is true nor armbians major goal is to be 'RPi compatible'  
Seems that they run out of their 'good eMMC' chips.   (maybe I should sell my 'old' OPi Pc+ on ebay, advertising that it is a 'fast one'  ). 
 
IMHO no! The only reason using NanoPi Duos 'motherboard' is during product development to get 'all features' easily accessible. If you still use it 'on production scale' of your project, just go for an *random H2+/H3 SBC* which deploys this features without a 'motherboard'. The main benefit of those SBCs is their size with a drawback that not everything is deployed on the board (this could also be a benefit if you don't want to have things deployed on the place the boardmaker deploys it, e.g. ETH is deployed 'on the false edge' for your project). But this is clearly a personal opinion....  
 
@Lion Wang - take care of this sort of feedback. At the moment, your BPi zero is a 'quad-core rip off' of the RPi 0 for a higher price than the original which would make it hard for most SBC customers to buy it instead of the 'original'. The fact that the camera connector is not compatible to RPi makes it even worse for a lot of use cases (you'll find a generic RPi compatible camera for ~6$ on aliexpress but a BPi compatible camera is in the range of 20$).  RPis videocore GPU works on recent kernels whereas Mali is 'work in progress' (but to my knowledge, nobody works really on it.  ).  So, your board needs some 'features' which makes it interesting for people which are annoyed by the RPi0. This could be (personal opinion).
eMMC instead of/combined with SD card  ETH on a pinheader (which you have) more than one USB port (maybe also on a pin-header) etc.  I said it once and now the second time,  don't bring this discussion to personal level between you and him which will end similar to the 'famous' BPi-R2 thread we had here and @Tido or myself will close it cause it's only about you don't understand why Thomas doesn't like your products and you're claiming that he must work for Xunlong.  This thread is a little bit like a baseball game - a lot of boring, not BPi0 related, stuff (maybe also provided by myself  ), and some new information we didn't know before (e.g. ETH is accessible through pin-header, 1.1/1.3V cpu regulation is on PL1 instead of PL6, first version of schematics). But as a real American @TonyMac32 can explain to you what happens in baseball after strike two...  (hint:  I'll close the thread maybe only for a 'cool down time' maybe forever cause I don't think we need a second 'BPi-R2 thread' again).  If you felt upset by Thomas and you can't deal with it, ignore him. If you're smart you 'extract' the key concerns he has about your product/company and evaluate if it's worth to improve/adapt it. 

Nice to get a fast response. But when you've ethernet there, this should be on your schematics! and described somewhere.  Most people would expect that the connector might be for powering (or maybe the USB otg). And to improve things, make sure that this information is not only visible here in the armbian forum.  It should also be in your documentation for this board. 

Maybe not for your use cases but for others. Not everyone has the same needs... I see use cases where size and wifi matters... Since OPi0 has heat issues,  and both other cheap small boards (opi0 and nanopi) have the annoying XR819 wifi.
 
don't start this again...  Thomas and you will fight on a personal level again, and @Tido will close the thread again...
 
Doesn't make sense... If they have an interesting board, I'm sure people from the Armbian community will work on this board (maybe not Thomas but others.. ) And as @@lex said... Edit: Getting basic armbian support for this board should not be that much work. Starting with a similar board (1.1V/1.3 V regulation) add wifi and configuration of fex for the pinheader and you'll have a basic armbian image for this board. 
 
I appreciate this, so let's start with the 4pin connector from my last post. 
 
FYI: Short version of the post with the picture which is lost somewhere in the www nirvana during upload.  I was too annoyed to write everything again...