manuti

  • Content Count

    349
  • Joined

  • Last visited

Reputation Activity

  1. Like
    manuti reacted to serkam in How to set static IP in eth0 and wlan0 in OPi Zero   
    Hi tkaiser and martinayotte.
     
    The real problem I was facing was due incorrect static IP address. I was trying to use 192.168.1.100 without /24. Doing this, nmtui automatically places /32 and the IP MASK is set to 255.255.255.255 and broadcast IP to 192.168.1.100 ( the same IP of my device).
     
    Setting IP to 192.168.1.100/24, all the rest is adjusted correctly ( 255.255.255.0 and 192.168.1.255 ).
     
    I did the same for wlan0 ( 192.168.1.99/24 ) and now both (eth0, wlan0) are working fine.
     
    I did a test using Visual Studio with linux plugin that use SSH to communicate with OPi Zero at eth0 and all worked fine. 
     
    As I intend to use wlan0 as AP to control a MQTT's network of IoTs devices, I wonder that the routing issue will be solved too.
     
    Thank you all people. Your support are great!
     
    Sergio
  2. Like
    manuti reacted to cloudalmasai in LeMaker Banana-Pi-Pro not recognized & WiFi   
    Thanks, that do the trick... Maybe you can add this to the notes in the download page... Thanks again, have a good day...
  3. Like
    manuti reacted to Igor in LeMaker Banana-Pi-Pro not recognized & WiFi   
    Firmware is missing. Try this:
    apt-get install armbian-firmware or 
    apt-get install armbian-firmware-full reboot or reload the module in between.
  4. Like
    manuti reacted to makama80 in Kerberos.io video surveillance installation on Armbian   
    UPDATE 11-FEB-2017: Version 2.2.0 is released: now including video recording in stead of only images and also a privacy option to black out areas that may not be filmed.
    UPDATE 09-FEB-2017: Version 2.2.1 is released: memory leak(s) fixed and in some cases video stopped recording. This should be fixed now. Download via this page.
     
    Kerberos.io (link) is a relative new video surveillance program focusing mainly on the Raspberry Pi. In collaboration with the owner of the github project I managed to get it working on my Orange Pi Plus and PCDuino3 nano using Armbian (Debian Jessie) and a Logitech UVC compatible USB webcam. It consists of 2 modules: the Machinery module and Web module. The machinery module was very Raspberry Pi specific, but is now updated and can also run with very little extra effort on Armbian. The Web module runs without any modification.
     
    Follow the instructions below and you should be able to install or compile it. Kerberos.io is very fast and has a modern interface. Furthermore it is (IMHO) a very nice alternative for zoneminder and motion.It also provides a videostream on a webpage.
     
    Follow the instructions below and share your comments, ideas etc.
     
    Method 1 (easy) - Install on Armbian Debian Jessie.
    Follow the instructions on the dedicated Armbian page (link). Here you will find an Armbian precompiled .deb armhf package. Further installation / configuration options can be found on the Kerberios.io webpages.
     
    Method 2 (advanced) - Compiling the machinery and web module on Armbian Debian Jessie.
    Install the following packages: sudo apt-get install pkg-config libavcodec-dev libavformat-dev libswscale-dev
    Follow the instructions on this page (link). Further installation / configuration options can be found on the Kerberios.io webpages.
     
     
    In all cases: please note that you must alter the camera configuration: default it comes with the Raspberry Pi camera that you probably won't have!
  5. Like
    manuti reacted to friendlyarm in NanoPi A64 board from FriendlyArm   
    Hi,
         You can refer to these photo to use the fan.



  6. Like
    manuti reacted to tkaiser in NanoPi A64 board from FriendlyArm   
    'The ODROID'? There are a lot of different ODROIDs but I think you're talking about S905 based C2? Benchmarks have been done a long time ago and S905 outperforms A64 everywhere. Since A64 is made in a 40nm process while S905 is already 28nm overheating adds to the lower performance of A64 devices since throttling jumps in pretty fast. I wrote scripts to ease the installation of RPi Monitor a long time ago (of course not tested with FA's OS images): http://www.cnx-software.com/2016/03/17/rpi-monitor-is-a-web-based-remote-monitor-for-arm-development-boards-such-as-raspberry-pi-and-orange-pi/#comment-524024
     
    No idea whether FA tweaked THS settings but with Allwinner's defaults performance of Pine64 was horribly low since their settings start to kill CPU cores instead of doing sane throttling. It took us some time to come up with better settings and Armbian's kernel for A64 also contains an in kernel corekeeper mechanism so that even if CPU cores get killed due to massive overheating they will be brought back online if temperatures decreased again.
     
    Anyway: A64 is about cheap and wrong expectations (this 64-bit thing). The low CPU performance is accompanied by a really old, slow and boring GPU (that is only OpenGL ES capable) and there are 2 USB ports max -- if I would want to deal with slow Cortex-A53 SoCs I would choose H5 instead (Orange Pi PC 2).
     
    BTW: Yes, you're reading correctly: A64 is slow as hell. You've been fooled by sysbench when you did your review. Sysbench can be used to heat SoCs but not to measure performance and especially compare different platforms (it's doing just a boring prime number calculation and this is for whatever reasons 15 times faster when code is compiled for ARMv8 -- RPi 3 would show way better sysbench numbers when not forced moronically to run binaries made for ARMv6 architecture built with a heavily outdated GCC version).
     
    In case you're interested to learn why sysbench sucks:
    https://forum.armbian.com/index.php/topic/751-rfc-support-cortex-a53arm64/#entry12462 https://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/?p=14439
  7. Like
    manuti reacted to tkaiser in NanoPi A64 board from FriendlyArm   
    So the board works happily. Better don't expect any HDMI output from A64 devices. HDMI driver in legacy images is a mess (and no one is going to fix it since some libs are blobs and sources aren't available) and mainline/vanilla is missing display output completely.
     
    Normally our Pine64 images should 'just work' but I haven't looked into settings yet and won't spend any time on this since A64 is basically boooooring as hell (for my use cases it's almost as crappy as Rasperries due to limited I/O bandwidth and for that what the average user wants A64 is simply the wrong SoC due to display situation. And who needs those 64-bit when we're talking about IoT stuff?)
     
    I also have not the slightest idea why other vendors start wasting ressources with A64 boards... maybe it's just marketing and product development madness from Allwinner's side (the specific business unit partners with Microsoft to bring stuff no one needs -- Win 10 IoT -- to A64 devices)
  8. Like
    manuti reacted to manuti in More proper testing - better Armbian experience   
    I tested Orange Pi PC on Orange Pi One, I don't know if this is useful:
    uname -a shows:
    orangepipc 4.9.0-sun8i #56 SMP Wed Nov 23 01:04:34 CET 2016 armv7l armv7l armv7l GNU/Linux armbianmonitor - u uploaded data to : http://sprunge.us/UPAE
     
    I don't know if you also want such format for feedback, but here it is:
     
    Card                        Boot         Network         HDMI         Install         Date                  Performed by
    -----------------------------------------------------------------------------------------------------------------------------
    Orange Pi One        yes             yes               no               yes            25.11.2016        manuti
     
    I update the image and install docker from the default repositories, in the webpage from armbianmonitor I can't see the temperature and of course the HDMI is not working.
     
  9. Like
    manuti reacted to DreamDreams in Building OpenWRT images for Orange Pi Zero with the Armbian kernel   
    What I did is simple:
    1. Install Armbian
    2. delete everything except /boot and /lib/modules from rootfs
    3. copy over OpenWRT rootfs 
     
    And that's it. This means I use u-boot, kernel, initrd and all settings from Armbian, only userland from OpenWRT. 
     
    And one minor tweak. Since how OpenWRT organize kernel modules is different, I have to do following:
    1. symlink all .ko files to /lib/modules/3.4.112 using
    for x in `find -name *.ko` do ln -s $x . done 2. OpenWRT's /sbin/kmodloader seems trying to open all ko files at once for stat and Armbian has a lot of modules under /lib/modules/3.4.112 dir so kmodloader will run out of file handle. I'm lazy to try to figure out which one is needed, so I simply change ulimit before kmodloader is ran in /etc/init.d/boot. Add one line at line 40:
    ulimit -n 10000
  10. Like
    manuti reacted to tkaiser in Building OpenWRT images for Orange Pi Zero with the Armbian kernel   
    Folks, please let's start to use this forum in a productive way. It's not about Armbian but about collecting knowledge and joining development efforts.
     
    What about posting a simple tutorial how to create an OpenWRT image based on Armbian? Next step: suggestion how to 'mis-use' Armbian's build system to produce 'foreign' OS Images?
     
    We currently support +40 SBC with our build system. And we *CARE* about settings and squeezing the max out of the boards unlike other projects (DietPi as a negative example). And when you look around the wheel gets reinvented every second. OpenWRT is one example, Kali Linux or Volumio are others. So sad.
  11. Like
    manuti reacted to nxtv2.0 in Mainline ethernet driver H3   
    Could this issue be a problem in the distro and the kernel?
    How do i troubleshoot this?
    And when compiling kernel , how do i configure it?
    Do i use defconfig ?
  12. Like
    manuti reacted to Igor in hummingboard-i2ex Mainline Kernel   
    It's actually not under download but well hidden here: http://www.armbian.com/kernel/
     

  13. Like
    manuti reacted to Gravelrash in HOWTO : NFS Server and Client Configuration   
    We will be configuring in a mode that allows both NFSv3 and NFSv4 clients to connect to access to the same share.
     
    Q. What are the benefits of an NFS share over a SAMBA share?
    A. This would take an article in itself! But as a brief reasoning, In a closed network (where you know every device), NFS is a fine choice. With a good network, throughput it disgustingly fast and at the same time less CPU intensive on the server. There are a lot of applications that support NFS "Out of the box" KODI being a common example. It's very simple to set up and you can toggle readonly on shares you don't need to be writeable. It only gets complicated if you want to start layering on security through LDAP/gssd. It's capable of very complex and complete security mechanisms... But you don't need them in this scenario.
     
    Q.   Why are we doing this and not limiting to NFSv4?
    A.   Flexibility, this will allow almost any device you have that supports reading and mounting NFS shares to connect and will also allow the share to be used to boot your clients from which will allow fast testing of new kernels etc.
     
    Q. Why would I want to do this?
    A. You can boot your dev boards from the NFS share to allow you to test new kernels quickly and simply
    A. You can map your shared locations in Multimedia clients quickly and easily.
    A. Your friends like to struggle with SAMBA so you can stay native and up your "geek cred"
     
    This HOWTO: will be split into distinct areas,
         "Section One" Install and Configure the server
         "Section Two" Configure client access.
         "Section Three" Boot from NFS share. (a separate document in its own right that will be constructed shortly).
     
     
    "Section One" Install and Configure the server

    Install NFS Server and Client
    apt-get update ; apt-get upgrade ; apt-get install autofs nfs-kernel-server nfs-common --install-recommends -f -y ; Now reboot
    sync ; reboot ; I will be making the following assumptions (just amend to suit your environment)
    1. You already have a working system!
    2. Your media to be shared is mounted via fstab by its label, in this case Disk1
    3. The mounted disk resides in the following folder /media/Disk1
    4. this mount has a folder inside called /Data

    Configure NFS Server (as root)
    cp -a /etc/exports /etc/exports.backup
    Then open and edit the /etc/exports file using your favourite editing tool:
    Edit and comment out ANY and ALL existing lines by adding a “#†in front the line.
    Setup NFS share for each mounted drive/folder you want to make available to the client devices
    the following will allow both v3 and v4 clients to access the same files
    # Export media to allow access for v3 and v4 clients /media/Disk1/Data *(rw,sync,insecure,no_root_squash,no_subtree_check,nohide) Explanation of above chosen parameters
    rw – allows read/write if you want to be able to delete or rename file
    async – Increases read/write performance. Only to be used for non-critical files.
    insecure – This setting allow clients (eg. Mac OS X) to use non-reserved ports to connect to the NFS server.
    no_subtree_check – Improves speed and reliability by eliminating permission checks on parent directories.
    nohide - makes it visible
    no_root_squash - *enables* write access for the connecting device root use on a NFS share
     
    Further explanations if you so desire can be found in the man page for NFS or from the following link
    http://linux.die.net/man/5/exports

    Starting / Stopping / Restarting NFS
    Once you have setup NFS server, you can Start / Stop / Restart NFS using the following command as root
    # Restart NFS server service nfs-kernel-server restart # Stop NFS server service nfs-kernel-server stop # Start NFS server # needed to disconnect already connected clients after changes have been made service nfs-kernel-server start Any time you make changes to /etc/exports in this scenario it is advisable to re export your shares using the following command as root
    export -ra Ok now we have the shares setup and accessible, we can start to use this for our full fat linux/mac clients and or configure our other "dev boards"  to boot from the NFS share(s).


    "Section Two" Configure client access.
     
    We now need to interrogate our NFS server to see what is being exported, use the command showmount and the servers ip address
    showmount -e "192.168.0.100" Export list for 192.168.0.100: /mnt/Disk1 * In this example it shows that the path we use to mount or share is "/mnt/Disk1" (and any folder below that is accessible to us)
    NFS Client Configuration v4 - NFSv4 clients must connect with relative address
    Use the mount command to mount a shared NFS directory from another machine, by typing a command line similar to the following at a terminal prompt as the root user (where 192.168.xxx.xxx is the server I.P. address)
    mount -t nfs -o vers=4 192.168.xxx.xxx:/ /home/â€your user nameâ€/nfs4 The mount point directory /home/â€your user nameâ€/nfs4 must already exist and there should be no files or subdirectories in the /home/â€your user nameâ€/nfs4 directory.
     
    Another way to mount an NFS share from your *server is to add a line to the /etc/fstab file. The basic needed is as below
    192.168.xxx.xxx:/    /home/â€your user nameâ€/nfs4    nfs    auto    0    0 NFS Client Configuration v3 - NFSv3 clients must use full address
    Use the mount command to mount a shared NFS directory from another machine, by typing a command line similar to the following at a terminal prompt as the root user (where 192.168.xxx.xxx is the server I.P. address)
    mount -t nfs -o vers=3 192.168.xxx.xxx:/media/Disk1/Data /home/â€your user nameâ€/nfs3 The mount point directory /home/â€your user nameâ€/nfs3 must already exist and there should be no files or subdirectories in the /home/â€your user nameâ€/nfs3 directory.
     
    "Section Three" Boot from NFS share.
    please refer to this document  on creating the image https://github.com/igorpecovnik/lib/blob/master/documentation/main-05-fel-boot.md - there will be an additional HOWTO & amendment to this HOWTO to cover this topic in more detail.
  14. Like
    manuti reacted to tkaiser in OPI pc USB HDD issue   
    If I were you I would take latest vanilla beta image from http://image.armbian.com/betaimages/ and then stop using stuff from last decade (mdraid, LVM) but rely on better stuff. I don't see the need for a stripe (RAID-0) here since OPi PC has just Fast Ethernet so you will always be bottlenecked by networking but by using btrfs you could use a combination of stripe and mirror: Striped data and mirrored metadata. Since btrfs uses checksums this allows to reliably check for data integrity even with a stripe for data:
    mkfs.btrfs -m raid1 -d raid0 /dev/sda /dev/sdb You can then run regular scrubs and get a warning if data got corrupted since checksums are mirrored on both drives. Does not protect against failing drives but using a 3rd drive to store snapshots (backup) is a good way to deal with this since most reasons for data loss are not dying disks but simple mistakes.
     
    Anyway: I would avoid RAID at all since the only purpose is increased availability and that's a joke with this kind of hardware anyway. If it's about data and not 99.99999% availability choosing a good backup strategy and looking after data integrity is always the better choice.
  15. Like
    manuti reacted to Igor in H2+/H3/H5/A64 Disp2 U-Boot video driver   
    4k works on legacy kernel, out of the box.
  16. Like
    manuti reacted to AnonymousPi in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Perform 'Step 1' per my guide above, then copy-paste the /etc/asound.conf file to be:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:0,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } The hint on what to do was in my comment within the suggested asound.conf in my original post:
    # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output
  17. Like
    manuti reacted to tkaiser in Armbian for OrangePi PC2, AllWinner H5   
    Well, it seems the guy doing the software stuff for Xunlong did some things correctly: He copied everything from longsleep's simpleimage stuff for Pine64 where applicable. But until he doesn't get rid off the smelly BSP stuff things might not work as expected. IIRC it has been already mentioned several times: Without someone wasting time on cleaning the mess up nothing will change.
     
    I already invited the Xunlong guy to become part of linux-sunxi community (something a bit hard given the amount of rude comments regarding vendor software offerings) and I really hope he joins. Since then it's maybe just a little dialogue between him and longsleep and the other guys to fix things.
     
    Regarding DVFS: I was a bit stupid before since I forgot which voltage regulator is used on OPI PC 2 (the good one known from larger Oranges accessible through I2C). Might be not a settings but more likely a driver issue so that voltage regulation currently doesn't work at all and the board boots with the cpufreq that is specified for u-boot (again 1008 MHz) which might be sane given that 1.1V are specified through resistors (at least that's the situation with H3 boards currently -- they come up with 1.1V if not configured otherwise)
     
    Why should anyone here waste his own time to debug issues the vendor has to solve and is able to solve (contact with Allwinner)? BSP stinks so unless you must use it you don't use it. Period. And all this stuff is totally unrelated to Armbian. We surely won't provide any alpha or beta based on that. Those issues have to be resolved first. But that has been said not just once before.
     
    Apart from that you're free to combine any Armbian arm64 rootfs with the Xunlong OS image skeletons (BTDT): feels slightly less crappy afterwards but has nothing to do with Armbian since our goal is to create images from scratch... that don't suck.
     
    You already mentioned your drawer: That's the perfect place for any H5 board currently if you're not a u-boot or kernel dev. Check situation in 2017 again (not kidding).
  18. Like
    manuti reacted to tkaiser in do I need a display   
    BTW: Just to save you some time. The only command you need to set up Wi-Fi then is 'nmtui'. No need to fiddle around in config files manually. Just choose your Wi-Fi network with nmtui, reboot, login again through Ethernet to get the 2nd IP address and then try to connect to this through Wi-Fi.
     
    We have some reports that this causes problems (maybe depending on network environment) so in case you run into troubles check this thread then: https://forum.armbian.com/index.php/topic/2907-opi-zero-incoming-ssh-cant-connect/
  19. Like
    manuti reacted to Igor in H2+/H3/H5/A64 Disp2 U-Boot video driver   
    Picture / font is as it should be. I am just refereeing to the fact that font is small due to high screen resolution and since I am usually using Picture In Picture mode for 2nd source. This way I got 4k screen cca. @12 inch  where u-boot font becomes super tiny small. I failed to made any usable picture, now I left office. I think the best way would be to limit u-boot screen size to 1080p and leave option to force higher with parameter. Such method can than be directly applied to sun4,5,6,7 ... 
  20. Like
    manuti reacted to ErwinH in More proper testing - better Armbian experience   
    To get cpufreq-info, temperature and throttling you need a kernel that has the patches for these drivers. The beta currently is still build with a kernel that doesn't have these patches. You can build your own kernel / image which do include these patches. https://github.com/megous/linux
     
    I've build my own image with this kernel and it's running nicely, with throttling, temperature/cpufreq readout and btrfs. When these patches either get mainline, or integrated in the armbian build system for the beta the One/Zero boards can run 4.9 kernel as well.
  21. Like
    manuti reacted to arox in USB Bluetooth dongle for Orange Pi Lite / Zero   
    https://www.reichelt.de/Bluetooth/LOGILINK-BT0015A/3/index.html?ACTION=3&GROUPID=5844&ARTICLE=170030&OFFSET=16&SID=96WDwXhKwQATMAAHrYxKs8aa7eb3331164bb14def41b33191fbf3&LANGUAGE=EN
     
    I used this one this a RPI. I just have ported my a2dp server on bluez5/pulseaudio/nanopi air (internal BT chip)
     
    - compatibility depends on bluez (and btusb kernel module) and not on board or distro, if customers report it works with "linux" or "ubuntu", then you will be able to have it working.
    - better use a class I dongle if you want a good range - but you will anyway hardly reach more than a few meters because a2dp device are generally class II
    - even better use a nanopi air : with eMMC and internal BT chip, you get the same price than an $8 board with crappy SD card and crappy dongle. Without antenna (not provided) this board is unusable, but with an IPX cheap antenna you get as good a range than with class I dongle for that usage.
    - be aware that with bluez5, you need pulseaudio, you can only use one BT sink at a time and you need workarounds to handle bugs in (pulse, bluez, dbus), workarounds that may depend on device specific profile connection management.
  22. Like
    manuti reacted to Igor in do I need a display   
    - via serial console
    - by mounting SD card on some linux and setting fixed IP in /etc/network/interfaces as this example:
    auto eth0 iface eth0 inet static address 192.0.2.7 netmask 255.255.255.0 gateway 192.0.2.254
  23. Like
    manuti reacted to tkaiser in do I need a display   
    Check the right thread: https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/
     
    We use the same booting settings as with the small NanoPi NEO (which means these three boards take quite a bit time to boot but don't exceed 2W) and I managed using Armbian's h3consumption tool to get idle consumption as low as 0.5W. When H3 devices are busy consumption increases but also not that much -- see here for example: https://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/?p=13626
     
    The problem with 'phone chargers' is that some do not provide more than 500 mA if the device in question doesn't speak one of the USB power delivery dialects (which no SBC does). And more importantly that many phone chargers simply suck. It might work but rule of thumb is 'a charger is not a PSU'. It should be noted that over 95 percent of 'Armbian problems' are related to either SD card or power supply issues
  24. Like
    manuti got a reaction from Igor in More proper testing - better Armbian experience   
    I tested Orange Pi PC on Orange Pi One, I don't know if this is useful:
    uname -a shows:
    orangepipc 4.9.0-sun8i #56 SMP Wed Nov 23 01:04:34 CET 2016 armv7l armv7l armv7l GNU/Linux armbianmonitor - u uploaded data to : http://sprunge.us/UPAE
     
    I don't know if you also want such format for feedback, but here it is:
     
    Card                        Boot         Network         HDMI         Install         Date                  Performed by
    -----------------------------------------------------------------------------------------------------------------------------
    Orange Pi One        yes             yes               no               yes            25.11.2016        manuti
     
    I update the image and install docker from the default repositories, in the webpage from armbianmonitor I can't see the temperature and of course the HDMI is not working.
     
  25. Like
    manuti got a reaction from lanefu in Orange Pi Zero went to the market   
    Orange boys are very busy nowadays new add-on board for 2$ for the Orange Pi Zero https://es.aliexpress.com/item/New-Orange-Pi-Zreo-Expansion-board-Interface-board-Development-board-beyond-Raspberry-Pi/32770665186.html?detailNewVersion=&categoryId=200004017