Nick
-
Posts
140 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Nick
-
-
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/LinuxMartin: 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: 0root@nanopineo:~# echo 5 >> /dev/i2c-0 -bash: echo: write error: Connection timed outroot@nanopineo:~# uname -a Linux nanopineo 4.11.12-sun8i #1 SMP Sun Oct 29 23:41:27 GMT 2017 armv7l armv7l armv7l GNU/LinuxI'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 adapteri2cdetect -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.
-
@martinayotte @candratech the problem is /dev/ttyS3 does not exist only /dev/ttyS0. How can I enable the ttyS3? Any ideas?
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.
-
One more question, will the standard OPiOne Ethernet interface work in a few weeks/months or do we always need an external USB one ?
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.
-
I'm pretty sure that HDMI isn't supported yet in V4.x of the kernel for any H3 device (though someone might correct me) Have you tried connecting your PC to the serial port?
Have a read of this: http://linux-sunxi.org/UART and this http://linux-sunxi.org/Xunlong_Orange_Pi_One
-
When you say nothing, have you tried the serial port?
The Armbian H3 images don't flash any LEDs and there are issues with the on board serial Ethernet at the moment (at least for the Orange Pi PC, I can't remember about the One). However it works extremely well with a USB ethernet converter, until the on board port is finished.
I'm not sure if HDMI works on the H3 boards yet, it's not something that I've had a need to try.
-
There is something weird going on with the SPI, I seem to be getting a spurious short clock pulse. See the attached pic:
The blue trace is the active low CS line, the yellow trace is the CLK line.
As you can see, the CS line goes low and sometime later there is a burst of 8 bits, but in between the two events there is a very short extra pulse on the CLK line. I'm guessing this explains why I can't talk to the poor slave device
Edit:
Finally got around to trying spitest...
root@opi:/# ./spitest -D /dev/spidev0.0 can't send spi message: Success Aborted root@opi:/# ./spitest -D /dev/spidev0.0 -s 50000 can't send spi message: Success Aborted root@opi:/# ./spitest -D /dev/spidev0.0 -l can't set spi mode: Invalid argument Aborted root@opi:/#
-
Which parameters in particular are you interested in?
Have you seen this, it is a good start for using SPI in linux http://linux-sunxi.org/SPIdev
-
Tell me about it, my clients keep getting in the way of playing with Armbian as well
Sadly the Ethernet performance hasn't improved at all for the moment. It's worth checking here every so often http://irclog.whitequark.org/linux-sunxi/search?q=montjoie as Montjoie developed the driver.
IMO the H3 Ethernet driver isn't stable enough for every day use yet and If I'm honest it's not something that I would look at in the short term, as right now I can get away with using a USB to Ethernet converter. If it isn't fixed in the future then I may get around to looking at it, but I've not written an EMAC driver before so I'm certainly not the best person to be debugging such things.
-
Hmm did this patch fail? Since otherwise it's a mystery to me.
And 6 min. vs. 19 isn't that amazing. Just 3 times faster. When we start to optimise server/storage stuff at customers I'm only satisfied if we exceed the 500%
That patch isn't being included, sorry I should have said that I'm building dev not default always helps when you have all of the information
500% is great, but I'll take anything right now. Of course, feel free to come over and tweak it for me, I'll PM you my address
-
I think you are right about the throwing them away as useless unless you have a particular application in mind. It's a nice idea, but like most things reality gets in the way ;-)
I have iSCSI running, 42 mins for the first compile (not including downloading of source code), 6 minutes for a subsequent build. I'm pretty sure cached builds were taking around 19 minutes over NFS, so a huge improvement thank you.
Not really for here, but it came up during the clean build of Armbian, uboot fails to build unless you change line 238 of configuration.sh from BOOTCONFIG="orangepi_h3_defconfig" to BOOTCONFIG="orangepi_pc_defconfig".
-
They look nice, sadly they are more expensive to get to the UK than Orange Pi PCs and I couldn't confirm if that was the 512 or 1GB version either
That said, I've run out of OPi PCs at the moment, I'm waiting for more to come from China.
I do like your cluster to go idea though, especially the pipe with a big fan at one end
I think I'll test out iSCSI first though ;-) -
Anyway, as long as it supports iSCSI reliably a superiour way to combine a VM (hosted on Windows, Linux or OS X) with iSCSI storage is
- define a local datastore to be used for /boot and /
Out of interest, how much does Xenial need for boot and root, is 1 or 2BG enough?
-
The 'Use Xenial as build host' recommendation is necessary
Noted, Xenial is downloading now (2Mbps ADSl means it takes a while
)The main difference between NAS and SAN is the use case: You use NAS if you want to share files between a couple of different hosts/users. That's what NAS protocols like SMB, NFS, AFP and so on are designed for (includes locking semantics, on-the-fly conversion between different encodings and other stuff). All this is not needed when it's about using one single 'share' by one host. This is where even the most primitve SAN implementations can shine.
Sharing with one host is fine for the moment at least, especially if I can get sub 10sec on the Armbian build timer
-
Thank you very much, I'll try that with the ReadyNAS tonight and let you know how I get on
Nano Pi AIR and I2C problem
in Allwinner sunxi
Posted
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.