-
Posts
3892 -
Joined
-
Last visited
Reputation Activity
-
martinayotte got a reaction from Echo in Enable 1-wire in kernel 4.9 on BananaPi
If you can switch to newest image because you simply added tons of applications, and tweaked tons of configs, what you can do is still download newest image, plug into a SDCard reader over one of the USB, then move the old /boot into /boot-OLD and copy the one from the new image from /mnt/boot into /boot. Probably, you will also need to install newest u-boot by doing :
dd if=/usr/lib/linux-u-boot-dev-orangepipc_5.27_armhf/u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8 The, reboot and see newest kernel, but still able to use you old applications
-
martinayotte got a reaction from Echo in Enable 1-wire in kernel 4.9 on BananaPi
There is also overlays provide in recent Mainline builds for A20, such /boot/dtb/overlay/sun7i-a20-w1-gpio.dtbo.
To enable it, simple edit /boot/armbianEnv.txt and add this :
overlays=w1-gpio And then reboot.
(Note : to use such overlays, your need a recent image, not upgrades from old image)
-
martinayotte got a reaction from manuti in Orange Pi Zero, Python GPIO Library
For all my Oranges, I'm using https://github.com/duxingkei33/orangepi_PC_gpio_pyH3
Be aware that on PiZero, the STATUS_LED is not on PA15 but on PA17, therefore you will need to tweak mapping.h to change that.
-
martinayotte got a reaction from TheNooter in Problems with Sound on Orange Pi Lite
There are several editors that can be used, but one of the easiest is call "nano".
type "nano /etc/asound.conf", edit what you need, than save it by saying "yes" when exiting with "ctrl-x".
-
martinayotte got a reaction from technik007_cz in SD card from ancient times
That makes me remembering when I purchased my first digital camera : 1Mpix per picture, 32MB FullSD. cost me $1000 ...
-
martinayotte got a reaction from lanefu in How to Get Python Shutdown GPIO/Button Script to Start at Boot on Orange Pi Zero
When adding any thing in /etc/rc.local, you need to make sure it done as a subprocess, not block /etc/rc.local from exiting.
So, you should call your script similar to :
nohup /usr/bin/python /root/hw_shutdown.py &
-
martinayotte got a reaction from manuti in How to Get Python Shutdown GPIO/Button Script to Start at Boot on Orange Pi Zero
When adding any thing in /etc/rc.local, you need to make sure it done as a subprocess, not block /etc/rc.local from exiting.
So, you should call your script similar to :
nohup /usr/bin/python /root/hw_shutdown.py &
-
martinayotte got a reaction from willmore in Testers wanted: sunxi Device Tree overlays
Since Dallas Semiconductor strongly suggest to use 4K7 Pull-Up for OneWire bus, I wouldn't rely on weak internal Pull-Ups which one some SoC are greater than 30K, especially if there are multiple sensor on the same bus or if those have long wires.
-
martinayotte got a reaction from willmore in Armbian for OrangePi PC2, AllWinner H5
FDTI/CH341/PL2303 have been added for next mainline nightly build
-
martinayotte reacted to zador.blood.stained in Testers wanted: sunxi Device Tree overlays
From Armbian documentation (https://docs.armbian.com/User-Guide_Allwinner_overlays/)
Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, …) don’t have a mechanism for detecting and identifying devices connected to the bus, so Linux kernel has to be told explicitly about the device and its configuration details.
While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default.
What do we want?
We want to add Device Tree overlays for the onboard interfaces and tested external devices so that they appear in future mainline Armbian images. This means that activating this type of hardware will not require recompiling the Device Tree or will require compiling just the overlay file which will be compatible with future kernel updates.
What kind of help do we expect?
We want people to participate in making and testing overlays for the hardware that they have.
Participation requirements:
An A10, A20 or H3 board that can boot the current mainline kernel Serial console adapter for getting the u-boot logs if they are needed Extra SD card to use for booting the nightly/beta images I2C, SPI or I2S (only A10 and A20 based boards since I2S driver is not present on H3 yet) device that you can connect to the board and that requires either generic driver (like SPIdev) or a special driver (available in the mainline kernel), with an exception of custom built boards that don't have commercially available compatible alternatives and devices that don't have in-tree kernel drivers. Some generic Linux knowledge (i.e. how to obtain a dmesg log, how to check file contents) At least a basic understanding of the hardware that you have and how does it integrate into Linux. For example I have no idea how to calibrate a resistive touch screen even if I can write a DT overlay for it. Please note that some hardware limitations (i.e. number of SPI chip selects, missing SPI DMA support) may affect possibility of supporting some devices
What overlays are already available?
Please check the README in the subdirectory for your SoC in the overlays repository: https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian
-
martinayotte got a reaction from zador.blood.stained in Armbian for OrangePi PC2, AllWinner H5
FDTI/CH341/PL2303 have been added for next mainline nightly build
-
martinayotte got a reaction from icsoft in Overlays in armbianEnv.txt
you wish to have i2c0 with /soc/i2c@01c2ac00 enabled, but you confusingly doing a "cat /proc/device-tree/soc/i2c\@01c2b400/status" which is not the same port.
Are you sure that none of the port shows up ? Did you check "dmesg" output ? Which board do you have ?
-
martinayotte got a reaction from mariel in orangepiplus2e kernel 4.10 only one core
What about testing with nightly image instead of doing upgrades ?
I did my own build about 3 weeks ago and I have the 4 cores.
-
-
-
martinayotte got a reaction from zakk in H3 SPI
That is normal. The way using "cat" is making things really dynamic, and yes you could add it into rc.local, but there is an easier way since few weeks :
Simply add the following in /boot/armbienEnv.txt :
overlays=sun8i-h3-spi0-spidev This will make uboot load it for you on every boot.
-
martinayotte got a reaction from zakk in H3 SPI
I've been using Dynamic Overlay to load SPIs into the DTS. There is no need to do any modprobe, since the Kernel will load it automatically when DTS is updated.
mkdir /sys/kernel/config/device-tree/overlays/spi cat spidev-enable.dtbo > /sys/kernel/config/device-tree/overlays/spi/dtbo
-
martinayotte got a reaction from MichalBor in OrangePi Zero - GPIO question
Why are you using the wiringpi ?
I'm using the https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 instead, and simple code like :
from pyA20.gpio import gpio from pyA20.gpio import port gpio.init() gpio.setcfg(port.PA7, gpio.INPUT) print gpio.input(port.PA7) -
martinayotte got a reaction from lanefu in [559] - GPIO Support for H2/H3 boards with a unified WiringPI library in a neat little package
No ! it is using kernel spidev transactions thru /dev/spidev*.* devices.
-
martinayotte got a reaction from awef in Orange Pi zero NOR Flash
You don't need to do all this since nightly builds already provides SPI-NOR support. The only thing you have to do is changing the partitions sizes in the current DT :
You will see the MTD partitions by doing "cat /proc/mtd", and you can use flashcp from mtd-utils to write to /dev/mtd0.
-
martinayotte got a reaction from zgoda_j in OrangePi PC GPIO UART and Arduino
For UARTs, you don't need those library, you only need to access kernel serial device, such /dev/ttyS1, using python-serial.
For example, the following piece of code will print any character received on RX :
import serial serport = serial.Serial("/dev/ttyS1", 115200, timeout=1) while True: while serport.inWaiting() > 0: c = serport.read() print c -
martinayotte got a reaction from lanefu in [559] - GPIO Support for H2/H3 boards with a unified WiringPI library in a neat little package
I don't know about specific WS2812 protocol, but doing an SPI transfer is about as simple as :
from pyA20 import spi spi.open("/dev/spidev0.0", mode=0, delay=0, bits_per_word=8, speed=5000000) data = [0,1,2,3,4,5,6,7,8,9] spi.xfer(data, len(data)) -
martinayotte got a reaction from willmore in OpiZ disable wireless entirely?
For me "time is the missing ingredient" ...
If you have some spare time, you could check the latency time between the FIFO fills, and also if CS is asserted during the whole large transfer, not only during the FIFO size of 64 bits.
-
martinayotte got a reaction from willmore in OpiZ disable wireless entirely?
I doubt there will be huge performance gain, because even with DMA, there will be some latency for DMA buffer been filled.
When I ported the FIFO large transfer, I said that when I get a chance, I will check the latency with logic analyser, but I didn't got chance yet.
-
martinayotte got a reaction from willmore in OpiZ disable wireless entirely?
It is good to disable it in the DT, but I presume leaving PA20 floating won't disable power since floating has similar effect to HIGH level on most chips.