Nick

Have you checked in detail (maybe even disconnecting everything from the I2C bus) for short circuits? I had the same issue for about a week not long ago, despite checking connections etc. there was a short to ground on one of the I2C lines that I never was able to explain. Once I had eventually found and fixed it, the problem went away.

I believe that the various PI boards do choose a random MAC address most / all of the time. If it helps you can specify a MAC address in the /etc/interfaces file Something like this should do it: # Network interfaces allow-hotplug eth0 iface eth0 inet dhcp hwaddress ether 08:00:00:00:00:01

I don't really know anything about vagrant at the moment, this is the first time that I've used it in anger so to speak, but that sounds plausible. It was a trivial fix to get things working again, I just thought that I would flag it.

I've just spun up a brand new vagrant installation using the instructions here https://docs.armbian.com/Developer-Guide_Using-Vagrant/ When I ran compile.sh inside the VM it installed a load of packages as it should, then eventually failed due to dialog not being installed. A simple apt install dialog fixed everything, presumably the build system needs to be updated to install dialog as well?

Hi, I've been trying to follow the instructions here https://docs.armbian.com/Developer-Guide_Using-Vagrant/ rather than using my current virtualbox setup however I fall over at the following spot: nick@Nick-desktop:~$ vagrant plugin install vagrant-disksize Installing the 'vagrant-disksize' plugin. This can take a few minutes... Bundler, the underlying system Vagrant uses to install plugins, reported an error. The error is shown below. These errors are usually caused by misconfigured plugin installations or transient network issues. The error from Bundler is: conflicting dependencies nokogiri (= 1.5.10) and nokogiri (= 1.8.1) Activated nokogiri-1.8.1 which does not match conflicting dependency (= 1.5.10) Conflicting dependency chains: nokogiri (= 1.8.1), 1.8.1 activated versus: vagrant-libvirt (> 0), 0.0.9 activated, depends on nokogiri (= 1.5.10) It looks as though it's a vagrant error rather than an Armbian issue in particular but wondered if anyone had solved it? This is the second issue that I've run into, I had a similar issue with another dependancy last night (I can't remember which one now) but managed to google my way past that. Here is uname for my machine Linux Nick-desktop 4.13.0-1-amd64 #1 SMP Debian 4.13.4-2 (2017-10-15) x86_64 GNU/Linux

Just to follow up... Starting with the image Igor linked to, that was installed and booted. I then modified the following (via SSH if it matters) armbianEnv.txt to add the overlay /etc/modules to add i2c-dev /etc/network/interfaces (to force a particular hw address so that my router pins the board to the same IP address every boot) installed i2c-tools via apt.

Hi guys, Thanks for the replies. Igor: I've just downloaded and burnt the image that you linked to and no luck. Here is the uname output just to confirm... Linux nanopineo 4.13.10-sunxi #65 SMP Tue Oct 31 00:09:00 CET 2017 armv7l armv7l armv7l GNU/Linux Martin: I've added pullups to make up for the lack of pullups on the Neo, one each for SCL and SDA. Looking at them with both a scope and a meter show them steady at 3V3 when running i2cdetect

My apologies if this is considered as hijacking the thread but I've been having issues with the I2C bus on a nanopi neo. I've tried enabling the dtb overlay in armbianEnv.txt as per the Armbian wiki, I've also tried editing the main dtb file to change i2c0 from disabled to okay (id haven't tried both at the same time). I have i2c-dev in /etc/modules None of this is making any difference I can't seem to access the devices on the bus at all. I have pullups fitted to the PCB and have verified that the devices are connected to the correct pins (3&5 of the GPIO connector). I can't see anything on SDA or SCL with the scope. root@nanopineo:~# dmesg | grep i2c [ 4.156128] i2c /dev entries driver [ 59.608197] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 71.128188] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0 root@nanopineo:~# echo 5 >> /dev/i2c-0 -bash: echo: write error: Connection timed out root@nanopineo:~# uname -a Linux nanopineo 4.11.12-sun8i #1 SMP Sun Oct 29 23:41:27 GMT 2017 armv7l armv7l armv7l GNU/Linux I've tried both the latest nightly and building Armbian from source, both react in the same way. root@nanopineo:~# i2cdetect -l i2c-0 i2c mv64xxx_i2c adapter I2C adapter i2cdetect -y 0 just shows -- for every address I have a feeling that I am missing something, I'm also not convinced that mv64xxx is the right adapter, I'm not sure why it just doesn't seem right.

Most likely yes, the A20 SoC has a 64byte hardware buffer according to the datasheet, so this is a hardware limitation not a driver limitation. As far as I'm aware the SPIdev driver doesn't make any attempt at caching data if you decide to send more than that so you will have to do it your self. It's been a while since I looked at the driver, but there may (should?) be a way of determining the maximum amount of data that can be handled if the driver isn't going to actively buffer it for you. This is a good place to start for all things SPI https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-next/drivers/spi

Sorry, I can't remember exactly, but it was something very silly like the USB -> UART converter had been disconnected. This ment that I was being logged out of SSH by the reboot command but the serial console didn't appear to change.

@ccfiel Vanilla isn't ready for OPi PC yet, it's still in dev (or was the last time that I checked) so you will have to build it from scratch. Start here: https://github.com/igorpecovnik/lib When following the build menu, you will need to make sure that you choose the option to build the dev branch.

What version of Armbian are you running, what kernel version etc? I'm running two Orange Pi PC boards here, both systems were compiled from the Dev branch i.e. V4 kernel, one about a month ago and one 2 or 3 months ago and they both have /dev/ttyS3. I've not tried using UART3 so I don't know if it actually works, but it is certainly present in /dev on both devices.

Does the thermal printer have a TTL port or is it normal RS 232? If it's a normal RS232 port (which it probably is) then you will either need to use a USB -> RS232 convertor, or one of these: http://s288.photobucket.com/user/ninexunix/media/Max3232.png.html Edit, just read that it has a TTL interface, my mistake! Have you tried swapping the wires? Pin 8 is TX from the Pi to the printer, Pin 10 is RX from the printer to the Pi, also I don't think ttyS0 is bound to those pins as it is normally used on the debug port. Try ttyS3 instead.

Technically it's working now, however there are a few patches that are required (Read this if you are interested http://forum.armbian.com/index.php/topic/850-move-to-dev/) and it isn't (when I last tried anyway) very stable at the moment. As to when it will be ready, that's upto the guy that is writing it, though I would imagine it will be sooner rather than later given that it is 90+% ready.