chradev

Dear All, While talking with our potential customers we found one uncovered GPR problem – the big “blind” range of antennas especially at bigger penetration. For now this problem is solving with a few scans with different antennas having different central frequencies, maximal penetrating depths and “blind” ranges respectively. Unfortunately, this approach has many disadvantages like more time for multiple scans, difficulties at synchronization of independent data, bigger archives etc. Our EGPR Application Controller is capable to capture data from many GPR antennas simultaneously and the software which can synchronize them at visualization effectively. That is why we start looking for an interest to extend our EGPR product in this new direction. Any comments and recommendations are welcome. Best regards EGPR Team

Hi to All, I would like to inform you about my post on Lime2-eMMC board application in Ground Penetrating Radar (GPR) system. I would also like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help. Best regards Chris

Hi to All, I am proud to announce that our effort to embed Olimex' Lime2-eMMC board in Application Controller for Ground Penetrating Radar (GPR) systems meets with success to the final phase. Our product EGPR (Easy Ground Penetrating Radar) is ready for demo and field tests. Everybody can take a look on our just finished web site. There is link to the real application from Demo page. We would like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help. Best regards EGPR team

Hi Sooperior, I also have many problems with USB OTG on Lime2 (A20) boards and customized Armbian build with mainline Kernel. The problems and some of the solutions are described in some posts on this forum thread. Best regards Chris

Hi Berkovsky, I have similar problem with Lime2-eMMC (A20 & AXP209) board and customized Armbian build always using latest mainline Kernel versions (4.8.10 at the moment). The problem is discussed from here to here but some HW dependency on UART0 RxD was found. Can you check if the bug disappears in case of serial console disconnecting if one is used. Best regards Chris

Thanks Zador, Unfortunately, you will not be able to test my use case because I have additional interconnection board and use GPIO-1 to connect console instead of Lime2 console connector. BTW the difference is a protection diode and power up resistor for UARD0 RxD line in case of connecting console via Lime2 console connector. In case of connecting it via GPIO-1 connector the line goes directly to chip pins. On the other hand all power on / off and reset functionality of Lime2 board is based on PMU chip (AXP209) and pushing PWR button have to power off the board in presence of DC-IN and battery. Best regards Chris

Hi to All, After setting rootfs read only I have found a problem with RPI Monitor. I have change RPI Monitor setup like described here. Because I have second SSD partition mounted on '/app/data' and used for writing I have changed: /usr/share/rpimonitor/web/stat -> /app/data/rmon/stat link to point to a folder on rw ssd rw partition and: daemon.datastore=/app/data/rmon in /etc/rpimonitor/daemon.conf. After starting the system RPI Monitor 'statistics.html' web page works fine but 'status.html' - not. All information on 'status.html' web page is accessible but it does not change showing 30-40 sec up time. This is probably the time the system is moving rootfs from rw to ro mode. Moving the rootfs to rw mode make 'status.html' web page to work fine again. I have also try to move all staff of '/usr/share/rpimonitor/web' folder to rw ssd partition but the problem stays there. BTW /etc and /var folders have rw layer (tempfs) mounted by unionfs-fuse and there is no other side effects observed for now. Any ideas where could be the problem? Best reagrds Chris

Thanks Zador, It can be but it cannot explain that when USB to serial adapter is connected to Lime2 console connector no such problem. I will try to find some test case based on your supposition. Best regards Chris

Hi Neomanic, I am using OTG in host mode for a long time and have other problem. When my STM32-H405 board is connected as CDC device and communication (~160 kbps from H405 to Lime2) is started for a long periods of time (5-10 hours) without apparent reason device is disconnected but continue to be visible by 'lsusb' command. The only way to revert to working state is by rebooting the system. A few months ago (earlier Kernel version) this problems have been happened much more frequently - after 1-2 hours. My investigation shown that some changes to musb driver have made the things better but did not solve the issue. That is why I have decided to use USB Host ports for critical communications and USB OTG for optional once. Best regards Chris

Thanks Dottgonzo, After your words I am definitely more peaceful. Best regards Chris

Hi to All, I have succeeded to get rootfs in read only mode but using unionfs-fuse instead of overlayfs & overlayroot. The idea is offered and reported here. It is also applied for RPi. Of course some change has to be applied because of using Kernel command line for rootfs options instead of /etc/fstab. Best regards Chris

Hi to All, The problem with rebooting instead of powering off looks more strange after last my findings. If brake off the console connection the board is powering off as before. EDIT: Disconnecting console RxD only is enough the problem to disappear. Main difference with the situation before the rise of this problem is that console and power button are connected via additional interconnection board. For wiring the console is used GPIO-1 connector. Additional wires are used for second power button wired in parallel to the Lime2 PWR one and mounted on the interconnection board for accessing it from the front panel. Any ideas where the problem is coming from? Best regards Chris

Thanks for your suggestion Dottgonzo, I tried it and succeeded out-of-the-box following your description also applied for RPi. Of course there was a small obstacle because in my use case rootfs options are transferred from uboot to kernel via its command line but it can be solved by a small change in mount_unionfs script. Fortunately, simplicity and long life time (9+ years) of the project are more important for me at the moment than possible speed lost. The only question for now is can we rely on Debian support to continue? Best regards Chris

Hi Lauhub, Why did you base your solution on Debian Jessie and Ubuntu overlayroot package while it is available in Xenial? As I have noted here the problem is probably the same in both cases. Any way I will try your modification a.s.a.p. Best regards Chris

Thanks Zador, Implemented backwards compatibility solves the problem with verbosity. Sorry for the question. Unfortunately, I have no time to look and understand all commits done. About rebooting instead of powering off this is the log with extended verbosity: The only fail: [FAILED] Failed to start Store Sound Card State. is not a problem because it exists for months. No other crashes especially the Kernel once. Unfortunately, I cannot say when this begins because relatively long time passed from my previous builds. Best regards Chris

Hi to All, Because the problem described above I have fixed my current build at USBIP support for sun8i default commit (21a5f49) by igorpecovnik on Oct 18, 2016. These days after new prototypes mounting and testing I have noticed a problem with 'poweroff' command which is resetting the board instead of powering it off. The same problem I have with Lime2 Power On/Off button (connected via PMU) because it finally run 'poweroff' command. The main differences with previous prototypes is that the front panel staff (LEDs, buttons and connectors) are: placed on a board and the GPIOs used was reordered to fit new board schematics; LEDs control is migrated to mainline Kernel driver gpio-leds as described here; Button control is migrated to mainline Kernel driver gpio-keys-polled as described here. They have no relations with the problem and works fine. Can somebody help me to find and solve the problem? Some help around fixing the 'verbosity' problem described above will also be very kind. Best ragards Chris

Hi Tomas, Today I have noticed change around verbosity control and find that with commit Re-enable crash detection, adopt armbianEnv.txt (by Tomas Kaiser) was removed deletion of '/boot/.verbose' file and verbosity control has been moved to U-Boot environment. Unfortunately, I am using old scheme relying on above file, environment coming from U-Boot build and written by me boot script. Is it possible to stay compatible with old verbosity control mechanism? What can I do in case of breaking backward compatibility? Best regards Chris

Thanks Arox, You are definitely right so I will stop looking in that direction anymore. Thanks again for all your assistance and the time spent. With hope all above to help you as well Chris

Hi to All, Thanks to Arox' assistance I have managed to get to my preferred reboot button control. Button is controlled by 'gpio-keys-polled' mainline Kernel driver as described here. Trigger Happy daemon is used to listen and execute an user script as described here. Finally, after installation of triggerhappy from the official Debian repository following files ware added: * /etc/triggerhappy/triggers.d/reboot.conf # EV_KEY BTN_0 1 /dev/input/event0 BTN_0 1 /bin/reboot.sh * /bin/reboot.sh with mode 766 #!/bin/bash /bin/echo none > /sys/class/leds/egpr-sys\:green\:usr/trigger /bin/echo timer > /sys/class/leds/egpr-sys\:red\:usr/trigger /bin/echo none > /sys/class/leds/egpr-sys\:blue\:usr/trigger /sbin/reboot and /etc/init.d/triggerhappy script is modified as follows: sed -i 's/--user nobody/--user root/g' /etc/init.d/triggerhappy to allow running privileged command. The effect of pushing the PG0 button is: the red system LED on PG0 starts blinking and system is restarted what is the main goal as a beginning. Additionally, file '/etc/udev/rules.d/72-system-reboot-button.rules' can be created for adding link to the right /dev/input/eventX device: # Handle user button with systemd ACTION=="remove", GOTO="power_switch_end" SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="egpr-keys", SYMLINK+="rebooter" LABEL="power_switch_end" After reboot ther will be the following: root@egpr:~# ls -la /dev/rebooter lrwxrwxrwx 1 root root 12 Oct 17 17:24 /dev/rebooter -> input/event0 which can be used if needed. Best regards Chris

Thanks Arox. That helps!!! Is it possible to have the same problem with udev? Best regards Chris

Thanks Arox, I am using polling driver because Allwinner A20 PGxx (and others ports available on Lime2 GPIO-1 connector) did not support external interrupts. Only part of PHxx and PIxx GPIOs are EINTxx and able to generate interrupts. About denounce function - it is already integrated in the gpio-keys-polling driver and denounce time could be set in device tree configuration so there is no problem with generation many events. In my opinion using gpio-key is better because it is based on interrupts but I have to add in my case one more 40 pin cable and connector to use a single EINT gpio from GPIO-2/3 Lime2 connectors. Best regards Chris

Thanks Arox, This is not a problem as well. I have changed /root/run.sh to: #!/bin/bash #/bin/echo Hello > /dev/ttyS0 /sbin/reboot without success. Best regards Chris

Thanks Arox, Unfortunately, it is not the problem. I have changed the mode (766 was before and should be executed with any rights) and even copy it to /bin directory (modifying the config file and restarting the daemon) without success. Any other ideas? BTW I have just found following error at boot: [ 3.545960] sun7i-a20-pinctrl 1c20800.pinctrl: unsupported function gpio-in on pin PG0 [ 3.545972] pinctrl core: failed to register map default (0): invalid type given [ 3.546355] input: egpr-keys as /devices/platform/egpr-keys/input/input0 but the events are definitely generated as tested. Could it be a problem with triggerhappy (and udev probably) when running as daemon? Best regards Chris

Thanks Arox, For sure but I need to make preparation to and reboot which needs my own script to be executed. It is definitely supported by udev but not sure for listening to the input events. I have tried triggerhappy daemon and it seems to work. I have found and install it from the official Debian repository. I have done manually following: root@egpr:~# thd --dump /dev/input/event0 EV_KEY BTN_0 1 /dev/input/event0 # BTN_0 1 command EV_KEY BTN_0 0 /dev/input/event0 # BTN_0 0 command for dumping supported events from /dev/input/event0, root@egpr:~# thd --dump /dev/input/event0 > thd.config for saving them in config file which was modified as: # EV_KEY BTN_0 1 /dev/input/event0 BTN_0 1 /root/run.sh to react on desired button push event, root@egpr:~# thd --listevents | grep BTN_0 BTN_0 to be sure that triggerhappy is listening to the prompt key, thd --triggers thd.config /dev/input/event0 to run triggerhappy manually from the console. After pushing the button the following was printed on the console: Executing trigger action: /root/run.sh Hello which is expected. Next step is to copy working triggers config file to '/etc/triggerhappy/triggers.d/' and to restart triggerhappy daemon. Unfortunately, I did not see expected printout 'Hello' on my console (/dev/ttyS0) as per /root/run.sh: #!/bin/bash /bin/echo Hello > /dev/ttyS0 Looking in '/etc/init.d/triggerhappy' the daemon is started with prompt arguments: DAEMON_ARGS="--daemon --triggers /etc/triggerhappy/triggers.d/ --socket /var/run/thd.socket --pidfile $PIDFILE --user nobody /dev/input/event*" Did you work with this service and where could be my fault? Best regarsd Chris

Thanks Arox, Event number is not a problem because thanks to udev it can be found as symbol link like: root@egpr:~# ls -la /dev/input/by-path/ total 0 drwxr-xr-x 2 root root 80 Oct 17 07:16 . drwxr-xr-x 3 root root 100 Oct 17 07:16 .. lrwxrwxrwx 1 root root 9 Oct 17 07:16 platform-1c2ac00.i2c-platform-axp20x-pek-event -> ../event1 lrwxrwxrwx 1 root root 9 Oct 17 07:16 platform-egpr-keys-event -> ../event0 where /dev/input/by-path/platform-egpr-keys-event in my case is linked to the right /dev/input/event0. Unfortunately, I did not understand who and when this link was created - suspect of command sequence: About the other staff it is not good idea to "invent the wheel" again. Best regards Chris