martinayotte

How did you figured that out ? Did the process no present anymore in "ps -ef" ? Do you grabbing log of both stderr/stdout output of the process, something like "python thescript.py > thescript.log 2>&1 &" ?

RTC is by default set to run with internal OSC, so no need for external one. How did you check that ? "hwclock" seem to provide the right time ...

This grid is confusing since this grid says pin31 == GPIO.22, which doesn't exist on A64, but at least the BCM equivalent is 37 like I've said, but you need to use GPIO.setmode(GPIO.BCM) for that numbering. I personnally relying more on shematics, and here is the one I've looked https://bananapi.gitbooks.io/bpi-m64/content/en/bpi-m64schematicdiagram.html

Like I've said the content of $PWD/output, so zImage, kernel modules, dtb. Because you will have to learn much more about all tools "dpkg-buildpackage" and others ...

This board is using A64 SoC, so only B/G/H banks are supporting interrupts. Also, here, you try using GPIO number 31 which is normally doesn't exist on A64. I don't know much about RPi.GPIO library, but maybe you should use defines like BPI_M64_31 which is, according to the source, GPIO_PB05 or GPIO37, then interrupt will work since B bank is on the list.

Unfortunately, this would be too complex ... You have to copies manually from files in $PWD/output to your existing installation using SSH.

And which board and SoC are you using ? BTW, I've just remember an older case where a person asked why input event wasn't working for him on H6, and we finally discovered that not all the GPIO banks provide interrupts on all GPIOs. He change the pin for another supporting interrupts and it was working fine . So, maybe it is the case here ...

Yes ! You need to debug more : - check that overlay is actually loaded during the u-boot phase. (Did you rebooted since the /boot/armbianEnv.txt changes ?) - do a "dmesg | grep -i spi" to figure out about any errors, (maybe pins are used elsewhere ?) Forget about this way, it is not Armbian way ... EDIT: Oh ! I didn't look thoroughly : You wrote "param_spinor_spi_bus=0" instead of "param_spidev_spi_bus=0" because of my own typo done previously ...

This is only showing the "idle" state, and maybe the kernel maintainer decided that is should show "output" from now on ... But this doesn't matter for the OneWire driver point of view ! This error is NOT related with the OneWire discussed above ! For this error, you need to investigate more, maybe the library your are using (and you didn't mentioned which one) is broken with newer kernel, I don't know ...

In fact, OneWire use that GPIO pin as a bi-directional pin, this mean that this driver decide itself if it is a input or output depending of the flow of data. Looking to all my boards where I've enabled OneWire, they all shows that the GPIO is seen as output. But the DS18B20 attached to them are working fine by doing "cat /sys/bus/w1/devices/28-000003ebdd28/w1_slave", they are showing the temperature, so it means that the GPIO was turned as input during the feedback of the sensor.

The U-Boot is located after the partition table but before the first partition. So, when you grabbed the U-Boot from Armbian image, and when you start the extract at byte # 0, it is also grabbing the partition table followed by U-Boot itself. U-Boot location is at byte #8192, so the extract should be done like that : dd if=ambian.img of=u-boot-only.img bs=1024 skip=8 count=1024 This will extract a 1MB image, big enough since native Armbian U-Boot is sized about 620KB ... Then, you can place it inside Balbes image without touching it own partition table by doing a "seek" : dd if=u-boot-only.img of=balbes-image.img bs=1024 seek=8 conv=notrunc That should do the job without scrapping Balbes original partition table ...

That is because Armbian doesn't have any BOOT partition, and doing "dd" without "skip/seek" will copy Armbian partition table over the Balbes one. To avoid that overwrite of partition table, you need to "skip" the first 8192 bytes when reading, and "seek" the same amount of bytes when writing into the other image.

I've started the work of switching SUNXI-DEV to 5.6.y, as usual, few DT duplicates and fixes ... But I've faced also a big change related to 'file_operations' been changed to 'proc_ops' in all places over the kernel, which cause that all our EXTRAWIFI needs to be fixed. I hope to get it done by the end of this evening ...

I've just tested with USB Storage on my OPi2E running DEV 5.5.0, it is working. BTW, on the OPi2E, all USBs are enabled by default directly in Main DT ...

No, it doesn't seems to work. I didn't figured out yet ... I presume, but I don't have any LIPO ...

As you can see, I was part of this thread ... And this doesn't provide access to existing Serial Debug port, but give an additional UART that requires new kernel config and devicetree node.

The /etc/resolv.conf is overwritten by NetworkManager ... Search in Google "NetworkManager /etc/resolv.conf", you will see tons of explanations !

Maybe Olimex Olinuxino-A64 ... I've one, but just figured out that it need a patch for RTC WakeUp : https://www.spinics.net/lists/arm-kernel/msg750059.html I'm currently doing new build to try it out ...

Although the battery connector allows to keep the RTC running while board is powered off, there is no PMIC to control power of the board from some kind of WakeUp Alarm.

According to Google, this mean Squid isn't properly configured, and produce errors in journal each time it try to resolve DNS.

You already mentioned that ... Doing a search on google seems that it is related to Squid. Are you runing Squid Proxy Server or something like that ?

So, process not currently running ... Hmmmm ! Not much clues here !

Do you have a SARG process running ? Verify it with "ps -ef | grep -i sarg"

Did you look about its content ? It maybe will give hints which app is writing into it... (on my boards, I don't even have any "journal" folder)