StuxNet

Perhaps we can make a quiz after all  It does the job: "promote members to a group when they reach a specific rank in the quiz"
https://invisioncommunity.com/files/file/8381-quizzes/
 
@tkaiser Would you like to design this member evaluation quiz?  Even if we have only this quiz its worth the trouble.
 

Well, some people would want to know more and some explanation must be present.

spidev0.1 means SPI0 with CS1
spidev1.0 means SPI1 with CS0
 

Forum does look "cleaner"..
There will always be those who join and post without searching / reading, people...in general... are a lazy bunch, and those with a little tech knowledge, think ….
Hey we are “special” and any tech issue we are having can not be anything WE are doing / not doing wrong, so it must be the software / hardware..
Right, I mean come on I got X number of years this so I must be right.
 
You must FORCE us provide the info. needed to help us, get us to READ the docs and How to’s.
 
The more effort you make us put into solving our own problems... the more we learn.
 
Because I used cheap SD cards for weeks without issue, once a issue came up, I dismissed the SD as the possible problem because it had never been an issue before,
and I JUST KNEW it could not be...well you know what happened….wasted hours of time...time I do not have much of…
 
By not listening to the folks here.. who know what’s what’s….I broke one of my basic rules….
 
“You must learn from other people’s mistakes. You can’t possibly live long enough to make them all yourself.”
Sam Levenson
 

That they ignore the meaning of 'open source' (or maybe simply don't understand what this means) is only part of the problem.
 
The people who try to help those brain damaged retards now for over 2 years still know what a shit show situation with 'the predecessor' Lamobo R1 was: you couldn't use a SATA disk, you couldn't use the network switch, there was not a single usable OS image and documenation was totally lacking (details with sources -- someone has my post unhidden and I don't think they'll delete my post another time). You could not make any use of this paperweight in the beginning and it took community unnecessarily long to fix all their stupid mistakes since they did not only not cooperate but were actively sabotaging our efforts (schematics have been released a year after the product went to market).
 
We know about MTK that (just until recently?) you didn't get sources from them unless you signed an NDA (preventing you from sharing/opening the sources) and these NDAs are pretty expensive.
 
Given the great reputation of this vendor, the amazing history of fails and their documented willingness to cheat on you as much as they can: why should we believe them they will open up sources? That's one of the most basic requirements to be able to just evaluate whether we want to invest time and efforts on this device or not.
 
But they do not even get why opening sources is important. Same with their understanding of 'documentation'. If I look today through the results of their drunken copy&paste monkey sitting on his keyboard and biting into the mouse (considering this 'writing technical documentation') then depending on which part of this 'documentation' I consult I get R2 power requirements that read either 12V/2A, 5V/2A or even just 5V/700mA and the power connector is either 5.5/2.1mm barrel, 4.4/1.6mm barrel or Micro USB. And it would take you insane amounts of time and efforts to get this information corrected since between you spotting the obvious mistake and their 'technical documentation' a brain damaged retard is sitting preventing any improvements.
 
Do we want to support devices where it's hard to get even most basic required information? Where technical documentation is just wrong all the times and will never get fixed?
 
Especially if we compare with other hardware vendors who don't behave like retards all day long. FriendlyELEC for example releases a new piece of hardware. Usually their engineers at the same time update the device's wiki page with schematics already released and of course version history. It takes just a single public complaint and their CEO writes you an email asking for details. You show them numbers, explain shortly what UAS is and why that matters, they phase out the old product and within 4 weeks there's a new and improved one.
 
You explain to FriendlyELEC people shortly why they should drop support for shitty old Allwinner kernels and use mainline kernel instead, CEO understands immediately that he doesn't understand details (not affected by Dunning-Kruger!), so their kernel dev is in CC:, it's easy to convince him to focus on mainline kernel and how to get there (just a few emails between Icenowy, me and them). In parallel you write the CEO that their kernel dev needs some time so please no pressure on him and days later we're here: https://github.com/friendlyarm/linux/tree/sunxi-4.11.y (still not perfect, but everything happens in the open, even 'community peer review' works as it should)
 
That's the difference between board vendors who respect and cooperate with community and able to learn/improve and brain damaged retards that do not even understand how horribly they actively hinder community to help them.

Oops! I didn't spot that one either!  Sorry @chwe ... better move it before Igor decides to cut our pay!!!

And in each SoC subforum (Allwinner A10/A20, Allwinner H2/H3, etc.) we could create a pinned locked thread named like "List of boards supported in this subforum" to improve navigation.

You'll find that this community is still relatively small, imo. Some posts can go longer than 3 days without a response. Please keep duplicate questions to a minimum.

That being said I've only tinkered with RetroOrangePi a couple times so I'm not gunna be the one to help you. The very (and I mean very) little knowledge I have tells me editing boot.cmd would be easiest. Don't quote me.
I do remember having resolution issues on a 720p TV (Opi PC+) though and this thread helped me customize the settings for a fix. Good luck.
 

I didn't thought it could even get more annoying.
 
I asked you to do a 'tracert 192.168.1.40' but you do a 'tracert 192.168.1.60' instead. Why exactly? Don't you get that we waste our time trying to help you but you show not even that little bit respect to follow guidance closely? You get all this help here for free and still do not cooperate at all. That's somewhat irritating.
 
At least it's obvious that as I already said networking is fucked up on your Windows box since the machine tries to reach 192.168.1.0/24 through the 'TAP-Windows Adapter V9' which is most probably a VPN connection. That explains why OPi Zero can ping the Windows box but not vice versa and why you're not able to login through Putty (problem located on your Windows box, needs to be fixed there). I won't further waste my spare time on your network problems though so please don't ask me why it's working with your Raspberries (most probably 'route print' on the Windows box could give an idea). I also asked for the output from 'arp -a' after you did the 'tracert 192.168.1.40' (to check for another problem but as usual you refuse to cooperate. Weird).
 
The difference between 'ping google.com' and 'traceroute 8.8.8.8' also shows that for whatever reasons DNS resolutions doesn't work on your OPi, this is also a local configuration problem. 
 
We're back at 'If I were you I would stop always making funny assumptions and claims and start to concentrate on the relevant stuff.' It would be really nice if you start to accept that adding to various other problems you ALSO have a local networking configuration issue and there's no need to post such stupid nonsense like 'I'm not the only one who face this kind of problem, i can garantee you that the Debian Jessie Image was not tested and Ethernet Driver is corrupted. (version 5.25 and 5.30)' any more. Thank you!
 
Why are such bold statements like yours above a problem? Since the next confused guy thinking Armbian has to be blamed for local problems fires up google, searches for 'armbian orange pi network problem', arrives at your post, doesn't read what happened and feels confident that 'there is a general Armbian network problem' starting to waste his and others time instead of focussing on basic troubleshooting steps.

The Armbian on the OPi's is "Plug and Play" as much as "leading edge" can be.
I am no "expert" in anything, I have no special talents but I am passionately curious.
 
I have never heard of U-boot util a few months back, I have never had any issues with any of the builds I was not the cause of.
 
I have setup 12 Zero's, a Zero plus h3 and the PC Plus, and played with a OP Prime board. Never a problem which was not known to me before hand (I read alot).
 
 This 1 sd card out of over 20 failing on a few boards means that this whole mess is a waste of time, the cheap DEV boards will have issues that is life.
 
Buying CHEAP sd cards / PSU (Yes TK I know.. Moron for doing so..I can own that) will always cost you more in the long run.
 
But all in all this whole Armbian thing is easy as PI.... ;~) It just works 99% of the time (when you follow the guides and listen to those who know).
OH I have 10 Rpi's they have their set of issues....
The boards are sold for development= the process of developing or being developed.

I always do, but my reaction is always "what I did wrong this time to get there"

keep in mind, you dont spend this money to the armbian devs. you spend it to xunlong. So, being rude to the guys who gives you all the support for free isn't the best idea to solve your problems right?
Especially if you're under pressure and need support from people that give it for free, be polite. It doesn't help you if they are pissed,  cause they can just stop answer to your tread and you're alone with your problems.
 
I can confirm for you that with a rev. 1.4 opi zero (powered over micro usb @2A PSU, with samsung evo 32gb sd-card) and debian on it works fine (see pictures, for sure good enough to work with ssh).  Getting four (if I have it right in mind) damaged boards at once seems you're a really unlucky guy or you're brick them somehow (btw I would never power them with alligator clips, that's a harakiri way to power sensitive things).
 
With Igor, martinayotte and tkaiser you had at least three guys answering to your questions who are good in problem solving.  Doing their proposals should help you immediately to determine if it is a software or a hardware problem.
 
 

So what are we arguing about? All those videos prove is that it's hardware. Not software. Which is what we've been saying all along.
 
 
I find it really curious that you show the OpiZero fully booted, swap everything over, then very briefly show it (not even the TV output) before cutting the video. Then you fully record the bootup and even login of the Raspi.
Not to mention your issues up until now were with multiple boards not just the OpiZero. The name of this thread is, problems with OPi PC+, after all but w/e. Here's what I think happened.

You shorted a couple/several pins, using your sketchy aligator clips on a brand new OPiZero that you waiting several weeks to get.
Now you're upset and looking to put the blame on someone. Even if that's not true, it still remains that you might have accidentally. Alligator clips can be slippery, next time use proper connectors.
 
It's not software. Have you ever even bothered trying a UART as suggested multiple times? You never did answer my question as to why (if it wasn't hardware) it would be working for literally everyone else.
 
P.s. Lol, regards? Yea right dude. Good day.

This screenshot is for sure the stock Android from eMMC !
If you are not a beginner with Linux and SBC, then you should have already hooked-up an USB Serial on the Debug Serial Port !
You will see that it is booting for sure from eMMC ...
 

You want to use those images? Don't. If you are experimenting, if you are using it for no purpose, than it's o.k. You just found one of many bugs, which are in automated built experimental images. The bug might be new, might be already solved in the mean time or some workaround exists - today's or tomorrow update might fix this or it might take more time. Those images comes as is. 

Hint for future: if you find some experimental image working, go to armbian-config and "freeze kernel and BSP upgrades" and your system won't receive kernel upgrades when doing "apt upgrade" until you unfreeze it again.

You'll find that this community is still relatively small, imo. Some posts can go longer than 3 days without a response. Please keep duplicate questions to a minimum.

That being said I've only tinkered with RetroOrangePi a couple times so I'm not gunna be the one to help you. The very (and I mean very) little knowledge I have tells me editing boot.cmd would be easiest. Don't quote me.
I do remember having resolution issues on a 720p TV (Opi PC+) though and this thread helped me customize the settings for a fix. Good luck.
 

I would suggest that you look at getting a different power supply, as mobile phone chargers are notorious for being unreliable for SBCs. They tend to either not provide their full current until the phone has *handshaked/negotiated* with the charger, are noisy, or drop their voltage they are loaded to below usable levels (as phone charging needs aren't that demanding). I would suggest you look at getting something like the white power supply (with interchangeable international plugs) for the raspberry pi. 
 
Also, please refrain from making multiple posts... someone *will* reply eventually

Really, I can't stand it any more
 
It's about the stuff those of us from the inner circle don't seem to care about: Pricing and use cases!
 
Orange Pi Zero Plus 2 is sold for $18.90 (H3) or $19.90 (H5). Why spending the additional dollar? No idea but customers might think since 'more expensive == better' or '5 is more than 3'.
 
Feature set of this board:
no Ethernet (forget about those use cases with NAS in mind) HDMI (so people will buy it since they think it would make up for something that can be used as a 'Desktop' -- that's the main difference to similar boards like OPi Zero or NanoPi NEO/Air --> no HDMI --> no multimedia/desktop use cases. Please forgot about those poor souls that are really trying to use shitty TV out on OPi Zero) WiFi (great, at least some connectivity. Not that shitty like XR819 but still 1T1R/2.4GHz crap) eMMC (no feature, just pleasing those who are confused about storage) Camera header (just like NanoPi Air) Now let's check software situation (totally different between H3 and H5 BTW!), then target audience and what works with H3 and H5:
If you just want to do some GPIO stuff you're plain stupid if you choose this Zero Plus 2 BS compared to the real Zero -- you pay at least $10 too much. If you want to use camera this only works with H3 since CSI support is still missing in mainline kernel -- @martinayottecare to accept that 'stable' kernel for all these boards is 'legacy' which is not available for H5 since the H5 BSP is such a horrible pile of shit that no one right in his mind will touch this ever? If you want to use this board as desktop again it's only reasonable with the H3 variant for VARIOUS reasons: no video acceleration with mainline, no GPU acceleration with mainline, not enough RAM when running a 64-bit Linux (we know this over a year now!) All of this is f*cking obvious if we start to look at this project from the outside and not only play 'developer sitting in the cellar and doing important stuff users don't understand anyway'. Use cases and pricing determine user expectations. I don't know why anyone would buy this OPi Zero Plus 2 (since if I want a boring Desktop Linux or a shitty retro gaming thingie then I would think first and get an OPi One or Lite instead). But at least the H3 variant is somewhat useable for the use cases it will be bought for. In contrast to the H5 variant which simply will suck.
 
It's plain stupid to support this board in Armbian and I finally give up now since it get's too boring to repeat the same stuff over and over again.
 
 

I was not talking about votes/polls. I was talking about why we behave like idiots and start to support boards solely based on the fact that a hardware vendor sent us dev samples worth few bucks.
 
Again (!!!) two examples: https://forum.armbian.com/index.php?/topic/4378-nightly-images/&do=findComment&comment=33601 (why do we start with something like Orange Pi Zero Plus 2 H5, it makes absolutely no sense at all --> Armbian no, Android yes/don't care)
 
Again (!!!) my proposal is not to start as soon as someone sends us hardware but to open a new thread in not yet existing 'Board Bring Up Discussion' subforum. There the person who's interested in a specific device has to elaborate on why it would be a good idea to support the specific hardware or whether it's not (vendor behaviour being one of the potential reasons. If a vendor doesn't provide correct specs/schematics, advertises with wrong numbers, doesn't fix documentation mistakes even if told multiple times, sends out partially defective dev samples, doesn't document timely if he exchanged relevant hardware parts -- I'm talking about AP6212 vs. AP6212A here -- that's a good reason to avoid that hardware and document this at the same time so surprised users get the idea why developers consider dealing with a specific hardware not worth their time. That way we might even see some vendors improving over time if their irresponsible behaviour is documented again and again).
 
I'm still only talking about a group decision based on a real discussion when/whether to start working on a device or not. No polls/votes, especially no user polls! If tomorrow a hypothetical 'PicoPi Bullcrap' for $5 is announced immediately 1000 new users sign up here and vote for Armbian support. We already experienced in the past that the cheaper the device the cheaper some people behave.
 
If Armbian might start such a transparent discussion process and users feel they need to ignore developer reasoning then they can start a poll thread on their own asking for a specific new donate button. And then later they're able to vote for board support by donating the amount of cash they were talking about in the first place. That way it's also ensured that we won't start on 'PicoPi Bullcrap' ever since those people only buying as cheap as possible are also too cheap to donate a single Cent.
 
And again: Board bring up is fun, board support the more boring part consuming time, energy and resources. We should triple check whether devices are worth getting 'supported' status or not. That's why I already talked about .playground vs. .wip. Allows developers to focus on fun stuff without risking to waste later time on the boring part. But as we could see with OPi 2G-IoT that does not even work with .wip boards
 

I assume you upgraded from 4.9.7 ? Than go back, until we find out where is the problem.

Install those two:
http://apt.armbian.com/pool/main/l/linux-4.9.7-sunxi/linux-dtb-next-sunxi_5.25_armhf.deb
http://apt.armbian.com/pool/main/l/linux-4.9.7-sunxi/linux-image-next-sunxi_5.25_armhf.deb

@msev
 
Sure, because of forum help I got it working so its my turn to help others. Yes, I use RC-522 in python.
 
Here are steps. 
1. Install Armbian image for orange pi zero. Please use Ubuntu Xenial (not the debian jessie). Reason for Ubuntu Xenial instead of debian jessie is that in debian jessie image by default only spi0 is enabled so you will only see /dev/spidev0.0 while in ubuntu xenial image you will see two entries /dev/spidev0.0 and /dev/spidev1.0 we need /dev/spidev1.0 as explained by zador.blood.stained. If you know how to enable spi1 in debian jessie, you may go for that too (its not available out of the box currently)
 
2. Make Connection as follows
MOSI ——————————> pin 19
MISO ——————————-> pin 21
SCLK ——————————-> pin 23
SDA ——————————–> pin 24
RST ———————————> pin 22
IRQ ———————————-> NONE
 
3. Install all the required stuff as follows
 
a) apt-get update b )apt-get install python-dev c) git clone https://github.com/duxingkei33/orangepi_PC_gpio_pyH3.git d) cd orangepi_PC_gpio_pyH3 e) python setup.py install f) cd .. g) git clone https://github.com/lthiery/SPI-Py.git h) cd SPI-Py i) python setup.py install j) cd .. k) git clone https://github.com/mxgxw/MFRC522-python.git l) cd MFRC522-python   4. Now its time to edit MFRC522.py. I am providing the diff with the original. < import pyA20.gpio as GPIO --- > import RPi.GPIO as GPIO 110c110 < def __init__(self, dev='/dev/spidev1.0', spd=1000000): --- > def __init__(self, dev='/dev/spidev0.0', spd=1000000): 112,114c112,114 < # GPIO.setmode(GPIO.BOARD) < # GPIO.setup(22, GPIO.OUT) < # GPIO.output(self.NRSTPD, 1) --- > GPIO.setmode(GPIO.BOARD) > GPIO.setup(22, GPIO.OUT) > GPIO.output(self.NRSTPD, 1) 384c384 < # GPIO.output(self.NRSTPD, 1) --- > GPIO.output(self.NRSTPD, 1) 5. Now Run Read.py
root@orangepizero:~/MFRC522-python# python Read.py Welcome to the MFRC522 data read example Press Ctrl-C to stop. Card read UID: 186,123,162,171 Size: 8 Sector 8 [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Yeah!! I managed to fix the overscanning issue!  (Credits go to this guy here for pointing me to the right direction!).
 
All in all my Picture was Overscanning 20 px on every edge.
 
At first I changed my resolution from the detected 720x576 to 680x536 (2 * -20 px = -40 px) in the script.bin. This results in an visible edge at the bottom of the screen and an visible edge on the right hand side (with a small black border!).
$ bin2fex /boot/script.bin ~/script.fex $ nano ~/script.fex find these lines: fb0_width = 0 fb0_height = 0 and change them to: fb0_width = 680 fb0_height = 536 then: $ fex2bin ~/script.fex ~/script.bin $ sudo cp ~/script.bin /boot $ sudo reboot  
Now the picture needs to be moved down and to the right by 40px to be fully visible!
 
Next I needed to manipulate TV ENCODER RE-SYNC PARAMETERS REGISTER of the H2+ SoC. For this I used a little tool called devmem2 which helped me to directly read and write to the memory, and thus allowed me to manipulate the H2+ registers!
 
devmem2 can be installed by using following commands:
wget http://free-electrons.com/pub/mirror/devmem2.c gcc ./devmem2.c sudo mv ./a.out /usr/local/bin/devmem2  
After Installing devmem2 I was able to shift the picture by manipulating the value on following Address: 0x01E00130! (=TV ENCODER RE-SYNC PARAMETERS REGISTER, this may differ depending on your SoC, check the Datasheet!)
First I read back the actual value (so I could revert back changes in case I messed anything up!):
 
$ sudo devmem2 0x01E00130 /dev/mem opened. Memory mapped at address 0xb6f0d000. Value at address 0x1E00130 (0xb6f0d130): 0x3005000A Now I was able to move the picture by writing a custom value to the register according to the R40 Datasheet: 
 
TV ENCODER RE-SYNC PARAMETERS REGISTER Datasheet entry:
 
Here is how I calculated this value with the help of the Datasheet:
31 ... Re-Sync Field => 0b 
30 ... Re-Sync Disable => 0b
29:27 ... not used => 000b
26:16 ... Vertical => 40d px => 0000101000b
15:11 ... not used => 00000b
10:0 ... Horizontal => 40d px => 0000101000b
 
All in All: 000000000101000000000000101000b => 0x00140028
So I used this command to set my display:
$ sudo devmem2 0x01E00130 w 0x00140028 EDIT: I created a small tool which does the work above for you
 
Finally I saved the command above in my rc.local file to shift the picture during boot.
$ sudo nano /etc/rc.local paste following line: devmem2 0x01E00130 w 0x00140028 This is a dirty workaround and should be fixed within the driver!
 
Pictures:
 
 
Hope this helps to correct your overscanning issues! This should also work with many other Allwinner based Boards. I read that some Bananapi users had a pretty similar problem with overscanning on AV out.

How I know that feeling. Totally understand, my bad. Keep up the good work man.

That's super fine, thanks for the mention and I'm glad to see it adopted that quickly!
I in fact made these script for a projet as well, I'm working on low latency audio software running on the NanoPi.
 
The only thing that has to be double checked in these scripts is the compatibility with other services running with systemd.
Yeah please tell me how it works when you've tested it!
 

Hello! Posting here as it's both the most recent and most precise topic about that issue.
 
I've managed to make two shell scripts to switch between Access Point and client mode for wifi.
 
I hope I haven't forgotten any other settings I've tweaked elsewhere on the system.
I'm not using nmcli/tui for creating the AccessPoint since the load option of the module makes this a bit tricky.
Instead this is standard hostapd for AP settings + dnsmasq for serving DHCP.
 
As stated in the files, this needs testing as well as checking regarding how to deal exactly with systemd services.
 
Save as stamode.sh, chmod +x stamode.sh and ./stamode
#! /bin/sh # Switch from Access Point mode to station mode (client mode to a wifi network) for AP6212. #TODO: Help, review and testers needed, especially for dealing with stopping/killing systemd services and process. # Stop running process for the AP /bin/systemctl stop hostapd kill $(cat /var/run/dnsmasq.pid) # Remove and re-add the wifi module, that time in station mode. rmmod dhd modprobe dhd # Update symlinks for interfaces rm /etc/network/interfaces ln -s interfaces.network-manager /etc/network/interfaces # Start normal network services provided by NM. /bin/systemctl start networking.service /bin/systemctl enable NetworkManager /bin/systemctl start NetworkManager # NM needs to be told to use that interface again /usr/bin/nmcli d set wlan0 managed yes # Wait for wifi to come up and show a list of networks in range sleep 8 /usr/bin/nmcli device wifi list Save as apmode.sh, chmod +x apmode.sh and ./stamode
#! /bin/sh # Switch from station mode (client mode to a wifi network) to Acess Point mode for AP6212. # Configuration of hostapd is found in /etc/hostapd/hostapd.conf or wherever the line "DAEMON_CONF" in /etc/default/hostapd points to. # Do not forget to uncomment the line mentioned above in /etc/default/hostapd # Edit /etc/network/interfaces with static IP for wlan0, example conf: # auto wlan0 # iface wlan0 inet static # address 192.168.101.1 # netmask 255.255.255.0 # dns-nameservers 192.168.101.1 # Configuration for DHCP server (using dnsmasq) is found in /etc/dnsmasq.conf, example conf: # dhcp-range=192.168.101.20,192.168.101.120,72h #TODO: Help, review and testers needed, especially for dealing with stopping/killing systemd services and process. # Stop and disable nm. If it's enabled it locks at boot for 5 minutes. # The dnsmasq processes aren't killed when nm stops and keep dhcp from working, kill them! /bin/systemctl stop NetworkManager /bin/systemctl disable NetworkManager kill $(cat /var/run/NetworkManager/dnsmasq.pid) kill $(cat /run/dnsmasq.br0.pid) # Remove and re-add the wifi module, that time in AP mode rmmod dhd modprobe dhd op_mode=2 # Update symlinks for interfaces rm /etc/network/interfaces ln -s interfaces.hostapd /etc/network/interfaces # Start using systemd and manually. Hostapd manages the interface, auth etc. and dnsmasq serves a DHCP server for clients connecting to the AP. /bin/systemctl start hostapd /usr/sbin/dnsmasq

Awesome dude! I was using FriendlyArm's kernel for awhile there since they accomplished this out of the box. However I've been meaning to tinker with this on Armbian for a while, cuz Armbian is dope,. Just haven't had the time. Thanks for beating me to it. Also, I've been kind of documenting my progress, proof of concept and use case for my NanoPi NeoAir.
 
Now, I hope it's cool but Tkaiser linked me to your post and I immediately made duplicates of your scripts and put them in a gist for personal reference and because I always assume links will die I also reference your scripts in the write up (if you can call it that) meanwhile being sure to give you proper credit  I'll be testing these out and give you feedback when my new order comes in the mail.
 
If you have any problem with that lemme know and I'll make changes.
 
Here's the gist: https://gist.github.com/BiTinerary/693b8949ed56d6c534d138b9ba2b837e
Here's the reference: https://github.com/BiTinerary/PocketServerPi/blob/master/README.md#installation (Second Paragraph)