Jump to content

paul alting

Members
  • Posts

    16
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Tasmania, Australia
  • Interests
    Simple living with high technology

Contact Methods

  • Website URL
    paulalting.com

Recent Profile Visitors

1373 profile views
  1. Thank you Martin for your assistance, but I found the better way forward was to do a complete re-install using mainline stable rather than using the nightly. It meant 4 to 6 hours of installing the required libraries from source and going through the complete re-compile task to get all the components back together to enable my application to run again. I guess it is a concern for me to find that just doing an update would cause such a malfunction at such a level. Hopefully going back to stable will be reliable again. I do love Armbian, and have so for a number of years now on various A20 boards, so guys, keep up this terrific system, it's so wonderful to use. Paul Alting van Geusau
  2. Hello Martin, Thank you for your reply. But after the upgrade, there is now no dtb file for the link to point to, so renaming would still not point to a dtb file. In the apt cache, there is a dtb-4.14.84 with all the A20 dtb file within. Is it possible that I pull out the cubieboard2 file and use this ?
  3. My trusty Cubieboard II has been working great for a long time now, but after doing an upgade, it fails to now boot. It operates headless as a simple server for my off-grid home energy system and Lithium battery monitoring. I found I wasn't able to post this over in the A20 section, so hopefully someone from over in that section will come over here to read. Details I still have in my terminal screen, so I can copy to here. From before update and upgrade, the log in banner is the following: Welcome to ARMBIAN 5.58.180812 nightly Debian GNU/Linux 9 (stretch) 4.14.90-sunxi From the upgrade command, showing packages to be upgraded: dev@cubieboard2:~$ sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: apt apt-transport-https apt-utils armbian-config armbian-firmware armbian-tools-stretch base-files hostapd libapt-inst2.0 libapt-pkg5.0 libnss-myhostname libpam-systemd libsystemd0 libudev1 linux-headers-next-sunxi linux-image-next-sunxi linux-libc-dev sunxi-tools systemd systemd-sysv tzdata udev 22 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 45.5 MB of archives. After this operation, 2,554 kB disk space will be freed. Do you want to continue? [Y/n] y Then the package getting and upgrading, notice the error with not being able to remove directories: Get:8 https://beta.armbian.com stretch/main armhf armbian-config all 5.72.190122 [40.7 kB] Get:9 https://beta.armbian.com stretch/main armhf armbian-firmware all 5.72.190122 [5,754 kB] Get:1 http://cdn-fastly.deb.debian.org/debian stretch/main armhf base-files armhf 9.9+deb9u7 [67.4 kB] Get:2 http://cdn-fastly.deb.debian.org/debian stretch/main armhf libapt-pkg5.0 armhf 1.4.9 [851 kB] Get:16 http://security.debian.org stretch/updates/main armhf libsystemd0 armhf 232-25+deb9u8 [260 kB] Get:17 http://security.debian.org stretch/updates/main armhf libnss-myhostname armhf 232-25+deb9u8 [103 kB] Get:18 http://security.debian.org stretch/updates/main armhf libpam-systemd armhf 232-25+deb9u8 [176 kB] Get:19 http://security.debian.org stretch/updates/main armhf systemd armhf 232-25+deb9u8 [2,274 kB] Get:3 http://cdn-fastly.deb.debian.org/debian stretch/main armhf libapt-inst2.0 armhf 1.4.9 [190 kB] Get:4 http://cdn-fastly.deb.debian.org/debian stretch/main armhf apt armhf 1.4.9 [1,199 kB] Get:20 http://security.debian.org stretch/updates/main armhf udev armhf 232-25+deb9u8 [1,077 kB] Get:5 http://cdn-fastly.deb.debian.org/debian stretch/main armhf apt-utils armhf 1.4.9 [398 kB] Get:6 http://cdn-fastly.deb.debian.org/debian stretch-updates/main armhf tzdata all 2018i-0+deb9u1 [273 kB] Get:21 http://security.debian.org stretch/updates/main armhf libudev1 armhf 232-25+deb9u8 [120 kB] Get:7 http://cdn-fastly.deb.debian.org/debian stretch/main armhf apt-transport-https armhf 1.4.9 [167 kB] Get:22 http://security.debian.org stretch/updates/main armhf systemd-sysv armhf 232-25+deb9u8 [81.8 kB] Get:10 https://beta.armbian.com stretch/main armhf armbian-tools-stretch armhf 5.72.190122 [12.4 kB] Get:11 https://beta.armbian.com stretch/stretch-utils armhf hostapd armhf 3:2.7-99~armbian5.72.190122+1 [384 kB] Get:12 https://beta.armbian.com stretch/main armhf linux-headers-next-sunxi armhf 5.72.190122 [10.6 MB] Get:13 https://beta.armbian.com stretch/main armhf linux-image-next-sunxi armhf 5.72.190122 [20.4 MB] Get:14 https://beta.armbian.com stretch/main armhf linux-libc-dev armhf 5.70.190112 [1,007 kB] Get:15 https://beta.armbian.com stretch/stretch-utils armhf sunxi-tools armhf 1.4.2-2~armbian5.72.190122+1 [40.1 kB] Fetched 45.5 MB in 12min 30s (60.6 kB/s) Preconfiguring packages ... (Reading database ... 57982 files and directories currently installed.) Preparing to unpack .../base-files_9.9+deb9u7_armhf.deb ... Unpacking base-files (9.9+deb9u7) over (9.9+deb9u6) ... Setting up base-files (9.9+deb9u7) ... Installing new version of config file /etc/debian_version ... (Reading database ... 57982 files and directories currently installed.) Preparing to unpack .../libapt-pkg5.0_1.4.9_armhf.deb ... Unpacking libapt-pkg5.0:armhf (1.4.9) over (1.4.8) ... Setting up libapt-pkg5.0:armhf (1.4.9) ... (Reading database ... 57982 files and directories currently installed.) Preparing to unpack .../libapt-inst2.0_1.4.9_armhf.deb ... Unpacking libapt-inst2.0:armhf (1.4.9) over (1.4.8) ... Preparing to unpack .../archives/apt_1.4.9_armhf.deb ... Unpacking apt (1.4.9) over (1.4.8) ... Setting up apt (1.4.9) ... (Reading database ... 57982 files and directories currently installed.) Preparing to unpack .../apt-utils_1.4.9_armhf.deb ... Unpacking apt-utils (1.4.9) over (1.4.8) ... Preparing to unpack .../libsystemd0_232-25+deb9u8_armhf.deb ... Unpacking libsystemd0:armhf (232-25+deb9u8) over (232-25+deb9u6) ... Setting up libsystemd0:armhf (232-25+deb9u8) ... (Reading database ... 57982 files and directories currently installed.) Preparing to unpack .../libnss-myhostname_232-25+deb9u8_armhf.deb ... Unpacking libnss-myhostname:armhf (232-25+deb9u8) over (232-25+deb9u6) ... Preparing to unpack .../libpam-systemd_232-25+deb9u8_armhf.deb ... Unpacking libpam-systemd:armhf (232-25+deb9u8) over (232-25+deb9u6) ... Preparing to unpack .../systemd_232-25+deb9u8_armhf.deb ... Unpacking systemd (232-25+deb9u8) over (232-25+deb9u6) ... Preparing to unpack .../udev_232-25+deb9u8_armhf.deb ... Unpacking udev (232-25+deb9u8) over (232-25+deb9u6) ... Preparing to unpack .../libudev1_232-25+deb9u8_armhf.deb ... Unpacking libudev1:armhf (232-25+deb9u8) over (232-25+deb9u6) ... Setting up libudev1:armhf (232-25+deb9u8) ... Setting up systemd (232-25+deb9u8) ... addgroup: The group `systemd-journal' already exists as a system group. Exiting. (Reading database ... 57982 files and directories currently installed.) Preparing to unpack .../00-systemd-sysv_232-25+deb9u8_armhf.deb ... Unpacking systemd-sysv (232-25+deb9u8) over (232-25+deb9u6) ... Preparing to unpack .../01-tzdata_2018i-0+deb9u1_all.deb ... Unpacking tzdata (2018i-0+deb9u1) over (2018g-0+deb9u1) ... Preparing to unpack .../02-apt-transport-https_1.4.9_armhf.deb ... Unpacking apt-transport-https (1.4.9) over (1.4.8) ... Preparing to unpack .../03-armbian-config_5.72.190122_all.deb ... Unpacking armbian-config (5.72.190122) over (5.67.181227) ... Preparing to unpack .../04-armbian-firmware_5.72.190122_all.deb ... Unpacking armbian-firmware (5.72.190122) over (5.67.181227) ... Preparing to unpack .../05-armbian-tools-stretch_5.72.190122_armhf.deb ... Unpacking armbian-tools-stretch (5.72.190122) over (5.67.181227) ... Preparing to unpack .../06-hostapd_3%3a2.7-99~armbian5.72.190122+1_armhf.deb ... Unpacking hostapd (3:2.7-99~armbian5.72.190122+1) over (3:2.6-99~armbian5.67.181227+1) ... Preparing to unpack .../07-linux-headers-next-sunxi_5.72.190122_armhf.deb ... Unpacking linux-headers-next-sunxi (5.72.190122) over (5.67.181227) ... dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi/scripts/selinux/mdp': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi/scripts/selinux/genheaders': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi/scripts/selinux': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi/scripts/mod': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi/scripts/kconfig': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi/scripts/dtc': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi/scripts/basic': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi/scripts': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.14.90-sunxi': Directory not empty Preparing to unpack .../08-linux-image-next-sunxi_5.72.190122_armhf.deb ... update-initramfs: Deleting /boot/initrd.img-4.14.90-sunxi Removing obsolete file uInitrd-4.14.90-sunxi Unpacking linux-image-next-sunxi (5.72.190122) over (5.67.181227) ... Preparing to unpack .../09-linux-libc-dev_5.70.190112_armhf.deb ... Unpacking linux-libc-dev (5.70.190112) over (4.9.130-2) ... Preparing to unpack .../10-sunxi-tools_1.4.2-2~armbian5.72.190122+1_armhf.deb ... Unpacking sunxi-tools (1.4.2-2~armbian5.72.190122+1) over (1.4.2-2~armbian5.67.181227+1) ... Setting up libapt-inst2.0:armhf (1.4.9) ... Setting up apt-transport-https (1.4.9) ... Setting up armbian-config (5.72.190122) ... Setting up sunxi-tools (1.4.2-2~armbian5.72.190122+1) ... Setting up libnss-myhostname:armhf (232-25+deb9u8) ... Setting up apt-utils (1.4.9) ... Setting up tzdata (2018i-0+deb9u1) ... Current default time zone: 'Australia/Hobart' Local time is now: Fri Jan 25 20:39:59 AEDT 2019. Universal Time is now: Fri Jan 25 09:39:59 UTC 2019. Run 'dpkg-reconfigure tzdata' if you wish to change it. Setting up systemd-sysv (232-25+deb9u8) ... Setting up hostapd (3:2.7-99~armbian5.72.190122+1) ... Setting up linux-headers-next-sunxi (5.72.190122) ... Compiling headers - please wait ... Setting up linux-libc-dev (5.70.190112) ... Setting up armbian-firmware (5.72.190122) ... Processing triggers for libc-bin (2.24-11+deb9u3) ... Setting up udev (232-25+deb9u8) ... addgroup: The group `input' already exists as a system group. Exiting. update-initramfs: deferring update (trigger activated) insserv: Service mountkernfs has to be enabled to start service udev Processing triggers for systemd (232-25+deb9u8) ... Processing triggers for man-db (2.7.6.1-2) ... Setting up linux-image-next-sunxi (5.72.190122) ... update-initramfs: Generating /boot/initrd.img-4.19.16-sunxi I: The initramfs will attempt to resume from /dev/zram2 I: (UUID=17b55684-d008-41ad-ac28-87f73566c4f6) I: Set the RESUME variable to override this. update-initramfs: Converting to u-boot format Processing triggers for dbus (1.10.26-0+deb9u1) ... Setting up armbian-tools-stretch (5.72.190122) ... Setting up libpam-systemd:armhf (232-25+deb9u8) ... Processing triggers for initramfs-tools (0.130) ... update-initramfs: Generating /boot/initrd.img-4.19.16-sunxi I: The initramfs will attempt to resume from /dev/zram2 I: (UUID=17b55684-d008-41ad-ac28-87f73566c4f6) I: Set the RESUME variable to override this. update-initramfs: Converting to u-boot format dev@cubieboard2:~$ logout So, I take the SD card and look at it from my main system. First the armbianEnv.txt file is as follows: verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun7i-a20 rootdev=UUID=8287e402-f361-446e-a757-592b7bf9ba34 rootfstype=ext4 overlays=i2c1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Looking at the boot dir, I can see there exists problems with links broken to dtb files. An image of the boot dir: Rather than me poking about and potentially making a small mess, could someone who understands better than I, help me out ? I would really appreciate any help to get my little Cubieboard II back up again.
  4. As mentioned, in armbian-config I set to nightly as well as installed kernel headers, but armbian-config does not confirm kernel headers were installed. Looking /usr/src it is empty, so no dtc there. Why is that ? If the device tree compiler was not so good, and the Armbian documentation details how to do dtc overlays, then I would have thought there would be many more people having difficulty with compiling and seeking solutions here on the forum. Also, why has not the device tree compiler then not updated to one that does work ?
  5. I have the dtc installed as part of Armbian, as mentioned version: I am guessing armbian-add-overlay is a wrapper around dtc, yes ? So, when I try a simple example, again the file I pointed to in my first post, from zandor-blood-stained, the little gpio-button.dts, I have the following results: With armbian add overlay: With dtc: So, my thinking is, that if armbian-add-overlay is a wrapper around dtc, then it is not pulling back the error codes correctly. Or, if armbian-add-overlay is in itself a device tree compiler, then it would seem to have a problem, as does the native dct. Is there something incorrect with this file from Zandor, has something changed in the way the compiler parses the file that makes this file now out of date and unusable ? I wonder if someone could try on their Armbian board with the latest mainline nightly could try this simple test for me ? Like I mentioned, I do not really know much about the structure of the device tree, and in particular, with armbian and the use of the available I/O. I guess I should have made separate posts, one for the dtc problems I am having and another for the GPIO problems. Many thanks - Paul
  6. Coming back to post my findings and to seek some further advice. Martin, I took a look at pyA20 and was able to compile just the appropriate sections to include into my C application. Looking at the code for pyA20, it accesses the GPIO via /dev/mem, going directly to the registers, which is sort of nice for speed I guess. But the problem is that it needs to be done as root, meaning that my application then needs to run as root, which I prefer not to do. I was not able to chown /dev/mem to enable to run non-root. Also, using this code from pyA20 may also be problematic for me in the longer term, if I wish to be able to use other boards other than A20. So, then coming back to using a driver based approach, by using libgpiod as mentioned in my previous post. Libgpiod allows GPIO access via /dev/gpiochipx and has bindings for C++ as well as Python, with the underlying library in C. I was able to use this to read a GPIO pin, PC23 on my Olimex LIME 2 board fine. Again, as root, but also after chown of /dev/gpiochip0 to group gpio and making me as user member of gpio group. I guess I would also be able to make that persistent as a uDev rule as well. I am having some difficulty in getting GPIO output to function with this library, and am not sure why yet, both using the C++ bindings and by direct C function call. So, coming back to something in my initial post, about Device Tree, which I am struggling to understand completely the syntax of. If I were to make a dts overlay for some GPIOs to describe their functionality, my questions are: Will I then be able to access the GPIO function say for example as /dev/mygpio ? If so, what advantage is there to having GPIO devices in the device tree ? And still, I would like to resolve the dts compiler on my board as detailed in my first post will not run ? Many questions I know, but I am sure there may be many others who have or will strike similar problems to me. I appreciate any who may be able to help me proceed further with this.
  7. Oh well, that sounds reasonable then, I will look more into using this and see how it works with what I am trying to do. One thing though, the Armbian documentation is quite well laid out and explained, though in this area of GPIO it does appear to lack the clarity I am seeking. But that clarity is coming from your answers as I get to work this out. I am looking forward to making good use of Armbian and to also provide some financial donation from any paid projects I have from it. Also, I would like to present some of my developments, maybe as a 'how to' for others. I will still like to find why I am not able to get the board to compile a dts using armbian-add-overlay ? I will keep the thread updated as I proceed.
  8. Okay, I could try using gpio_lib from pyA20, but is that based on the old method and not the newer method to access GPIO ? I could also look at how to make up a pin mapping for ArmbianIO. I use Eclipse on Debian 'testing' on Intel and cross compile for ARM using Linaro 7.3.1 toolchain. Getting the I2C working was a bit of work, but not as much as for simple I/O. I wonder how I will go with SPI or CAN later on Many thanks and any other help is really appreciated.
  9. Yes, I am at a loss also. I have looked at pyA20 and wasn't sure how well it would link to what I wish to do in C/C++, and having a preference to doing it all with standard C/C++ code and libraries. I have just installed to the LIME 2 board the libgpiod library as it appears from my reading to support the new character based devices for gpio. From: Libgpiod For further ideas I also looked over: https://github.com/sgjava/userspaceio Again, many thanks for your assistance.
  10. Hello Martinayotte, Thank you for your response. Yes, when I grep /boot/config-* for CONFIG_GPIO_SYSFS, it returns with Yes. The other thing, I understand that using /sys/class/ will be or is deprecated and that using /dev/gpio* is the method to use. I have /dev/gpiochip0 and /dev/gpiochip1 listed. I was just reading through Larry's thread on Armbian IO Proposal, and noticed you had some posts there as well. But, there is no pin definition for any Olimex boards and wonder why not ? Would it be possible to include the pin mappings for other boards supported by Armbian such as those from Olimex ? I intend to buy more Olimex boards as from the Armbian list of supported boards, I think Olimex suits my needs quite well. I am looking to use these in industrial sites for low level automation. Also for renewable energy systems as a central control system. Santé Paul
  11. paul alting

    paul alting

  12. Hello all, Firstly, a huge thank you to Igor and team for Armbian, I love it and appreciate you for the effort and time you have dedicated to this amazing project, thank you. I have used Armbian on Cubieboard II for a number of years now, running my main server with QuadlogSCADA for my off-grid renewable system at my home. Now, I have had an Olimex LIME-2 eMMC4GB board sitting idle for a while on the corner of my desk and over the past few weeks have been inspired to do some programming with it. So, on this LIME2 board, I have the latest nightly builds, installed to eMMC, all working fine so far. Then, I though to connect a standard 20x4 character LCD to this board using I2C, by setting in armbian-config the overlay for I2C1. I wrote some C code to output data to this display over I2C at address 0x3f and, again, all works wonderfully well, great. Next, I thought, as part of my development toward a larger project, I want to be able to work with discrete GPIO pins, and this is where I have hit a solid rock wall. I have read all the documentation, over and over many times. I have looked at much to do with Armbian on Github in relation to using GPIO for A20 devices, both with legacy kernel and mainline. I have read so much, but have not found the answer that enables me to progress, so, I write this post. Again, I use an Olimex LIME-2 with 4GB of eMMC. I have, in armbian-config, set it to use the nightly builds, as well as installed the kernel headers. I have read this post: Armbain add overlay can not fine headers (solved) I have read this post from March 2018 to do with GPIO problems by user 24Lines: A20-LIME2 can not use GPIO on PG port From that post, if I try to test with PC23, by the following command to export: echo 87 > /sys/class/gpio/export I get the following (using sudo of course) -bash: /sys/class/gpio/export: No such file or directory Then, maybe I need to play around with overlays, so, I try. I pick up a simple overlay from zandor-blood-stained github, the GPIO-button.dts file, from: gpio-button.dts I thought, yes, I could use this as the overlay mentions GPIO by polling or by interrupt and it looks fairly simple in principle to use. So, I copy this file across to my home location on the LIME board and then, following the documentation on compiling dts to dtc I give the command: armbian-add-overlay gpio-button.dts To which I get the following: Error: dtc does not support compiling overlays I check the version of dtc and it tells me it is DTC 1.4.2 So, my question is, do I specifically need to provide an overlay to use gpio as simple bit based I/O in Armbian ? If yes, then where did I miss the correct instruction on how to do this ? Also, I have looked at the C++ code for A20 GPIO which is based on gpio_lib at Olimex site: A20-GPIO It throws an exception on the first Init() function, so, is this code applicable to mainline kernel and if so, how can it then be used ? If not, then can I still use gpio_lib in some way, I guess after setting up in some way to use GPIO ? Igor, I am really grateful for your time and have just watched your video at BalCCon2K17 conference presentation, very good I have uploaded the board config as of right now, after all updates : armbianmonitor config I hope you or Zandor or Thomas or others may be able to help me in getting GPIO working so I may use it in my C/C++ applications. From the little island down under under - Paul Alting van Geusau (aka Von Baron)
  13. I struck this problem today, after doing upgrade to my headless CB2 server, which has been working away faultlessly for many many months. After upgrade it did not appear to boot normally, I could not even SSH into it to find out what was going on, so I came to the forum to see if this was an isolated case or if others had experienced the same. At present CB2 SCADA HTTP server is now down and I am trying to figure how to get it back alive without a major rebuild. Igor, I do appreciate the countless hours of effort you have put in, Armbian has been a pleasure and a gift to use, thankyou
  14. Steven, that works very nicely, thank you for your effort in providing the u-boot bin file and instructions Now I can play with my Cubieboard2 again. I will also be using the later vanilla image as well, to become more familiar with both and what will work better for my application. I have developed an application in C that is essentially a SCADA system, that talks Modbus to devices like Arduinos or PLCs. It has inbuilt HTTP server to serve up static files as well as listen to AJAX calls for real time data updates. I wanted to look into CAN bus and how I can make use of this also to talk to my Lithium battery management system, which currently talks to an Arduino DUE via CAN bus. Thanks again Steven, Paul
  15. Steven, is there a quick or easy method to changing the U-Boot ? When I boot the Cubieboard2, I see it has U-Boot 2016-01 It starts okay, with U-boot messages before saying 'Starting Kernel" and promptly powering off. The messages are being displayed on the HDMI monitor, but it happens fast, so I don't get time to study the full content. So, I looked at installing the toolchain to be able to build the complete system, from Igor's Git. Problem for me I think is that my main development system is GNU/Linux Mint LMDE2, based on Debian directly, not Ubuntu, and I don't seem to be able to install "gcc-arm-linux-gnueabihf", which is needed by Igor's toolchain setup. So, have spent four days researching about all this and haven't yet found an answer to being able to install the correct toolchain on my system, and I really don't want to install Ubuntu, although I have loved using for many years now. ____________ Paul - VK7KPA
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines