Gyver

Members
  • Content Count

    9
  • Joined

  • Last visited

About Gyver

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Gyver

    Hummingboard additional UART

    Please excuse me, I havent understood well what should I do in the dtb since it was already "okay". I just disabled it but the behavior is the same as before, it stops boot as a normal keyboard.
  2. Gyver

    Hummingboard additional UART

    I just checked the file and it is already in "okay", which i think means that it is enabled in device tree configuration, If I disable it in the dtb means that it will not be available for ubott, but also for linux system, right?
  3. Gyver

    Hummingboard additional UART

    I am getting a problem not being able to connect to serial uart on a Humming board base using armbian. The ports available on devices are /dev/ttymcx0 and 3, so I tested looping back tx and rx of pins 8 and 10 of 26-pin header and tested echoed characters through minicom. The port corresponding to those pins is ttymcx0, and connecting my gps it seems to work, but after I reboot the board, booting stops, since it detects characters from the port coming from the gps and this stops booting process. I previously posted this problem and I was told that I should look for another port, but there is not another port documented in the official solid run documents (https://www.solid-run.com/freescale-imx6-family/hummingboard/hummingboard-documentation-block-diagram/), so I would like to know if I can disable this behavior somehow in order to be able to use the serial uart, and to avoid to stop the booting process. Thank you so much in advance. Guido
  4. Gyver

    Hummingboard additional UART

    in armbian I can see only /dev/ttymcx0 and 3 as devices, according to these pinout http://forum.solid-run.com/hummingboard-hardware-lab-f18/gpio-header-pinout-t1476.html there is only one uart and it answers to /dev/ttymcx0. I am abit confused if it is not present in the documentation, also schematics show one uart: http://download.solid-run.com/pub/solidrun/HummingBoard/rev-3.0/HummingBoard-rev-3_0-schematics.pdf Hello, I am having a problem using the uart and I guess it is related with this topic. I am trying to make my Hummingboard to communicate via UART with a serial ublox GPS. I identified that the right device in armbian (5.34) is /dev/ttymxc0 since it echoes characters when I join tx/rx together. When I connect the GPS it starts sending gps data normally, but when I have to reboot the hummingboard, it does not boot. I connected a screen to the HDMI interface to see what was happening, and I get the screen message as if a key had been pressed in order to stop booting process, so the boot stops here and the hummingboard does not come up. When I disconnect the GPS power or the UART, the HB boots normally, and the gpsd gets the serial port. when the gpsd is closed, agetty takes the control of the uart and I cannot use it again until I reboot. I concluded that the boot was configured to take the console keyboard from the UART, so I modified /boot/boot.cmd as suggested in this thread; I found the line: if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttymxc0,115200"; fi So I changed to if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "console=tty1"; fi in order to avoid the boot to grab the ttymxc0 serial port. I recompiled the boot.cmd and rebooted, but the problem persists. The boot is still stopped due to an abnormal keypress. I have no idea of how to make it work, since I have tried the procedure above and also explored the alternative of resetting via hardware the GPS during hummingboard boot, but it still stops the booting. The GPS will be permanently connected to the hummingboard, so I cannot disconnect it everytime I reboot. Do you have any ideas about what would be the problem? How to avoid the boot to depend on the uart? I also checked the boot configuration built on the kernel: cat /boot/config-4.13.12-cubox |grep ttymxc and th result was: CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" Does this mean that I have to recompile the kernel to solve it? Thanks very much in advance Regards
  5. Hello, I am having a problem using the uart and I guess it is related with this topic. I am trying to make my Hummingboard to communicate via UART with a serial ublox GPS. I identified that the right device in armbian (5.34) is /dev/ttymxc0 since it echoes characters when I join tx/rx together. When I connect the GPS it starts sending gps data normally, but when I have to reboot the hummingboard, it does not boot. I connected a screen to the HDMI interface to see what was happening, and I get the screen message as if a key had been pressed in order to stop booting process, so the boot stops here and the hummingboard does not come up. When I disconnect the GPS power or the UART, the HB boots normally, and the gpsd gets the serial port. when the gpsd is closed, agetty takes the control of the uart and I cannot use it again until I reboot. I concluded that the boot was configured to take the console keyboard from the UART, so I modified /boot/boot.cmd as suggested in this thread; I found the line: if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttymxc0,115200"; fi So I changed to if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "console=tty1"; fi in order to avoid the boot to grab the ttymxc0 serial port. I recompiled the boot.cmd and rebooted, but the problem persists. The boot is still stopped due to an abnormal keypress. I have no idea of how to make it work, since I have tried the procedure above and also explored the alternative of resetting via hardware the GPS during hummingboard boot, but it still stops the booting. The GPS will be permanently connected to the hummingboard, so I cannot disconnect it everytime I reboot. Do you have any ideas about what would be the problem? How to avoid the boot to depend on the uart? I also checked the boot configuration built on the kernel: cat /boot/config-4.13.12-cubox |grep ttymxc and th result was: CONFIG_CMDLINE="noinitrd console=ttymxc0,115200" Does this mean that I have to recompile the kernel to solve it? Thanks very much in advance Regards
  6. Gyver

    Hummingboard Edge - boot problem

    cubox-i 3.14.79-cubox ARMBIAN 5.25 stable Ubuntu 16.04.1 LTS 3.14.79-cubox
  7. Gyver

    Hummingboard Edge - boot problem

    Hello to everyone, I am having a similar problem, but with a hummingboard we bought recently. I downloaded the armbian image with ubuntu (server) and we put this image in two hummingboards: one "I4P" (marked with a sticker on the back) and another one that we recently bought. On the first one the image works perfectly, but on the second one it stops during boot; We are attaching here a screenshot of the boot sequence. Given that it says it does not find the file "/boot/dtb/imx6-..." we found on the solidrun forum that the different u-boot version would check for dtb files into /boot instead of /boot/dtb/ and so we copied all dtbs into /boot/ but we obtained the same screenshot. Do you know what would be the issue? Initially we thought that it was a problem of only one of the boards but then we reproduced the problem on all 3 hummingboards we bought. Best regards and many thanks in advance.
  8. Gyver

    pps-gpio in HummingBoard

    Thanks a lot! I found that the phandle was 0x24 and put that number as first cell in gpios. The pps source is created now and it works. God Blesses! Thank you!
  9. Hello everyone, I was used to use the cubox-i running on a hummingboard (2 years ago) and tried to install a pps source using pps-gpio module and the GPIO1 (pin 7) of the HummingBoard jumpers. Given that pps-gpio requires an entry in the device tree for pps, and I couldn't find/patch/recompile again sources (image was built by another person), I decompiled the imx6q-hummingvboard.dtb present in /boot, then modified it adding : pps { compatible = "pps-gpio"; gpios = <0x01 0x01 0x01>; }; and then I recompiled this source and copied into /boot. When I rebooted, the new /dev/pps1 was created and the pulses were received by the hummingboard (checked using ppstest program from pps-tools package). Then I installed the armbian in the same Hummingboard (from image downloaded from this website) and followed the same procedure; the problem is that i got the error in dmesg: [ 0.090676] pps_core: LinuxPPS API ver. 1 registered [ 0.090685] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 23.022017] /pps: could not get #gpio-cells for /interrupt-controller@00a01000 [ 23.027445] pps-gpio pps.24: failed to get GPIO from device tree [ 23.039236] pps-gpio: probe of pps.24 failed with error -22 and the pps source is not created. Would anyone help me with the right definition of the device tree in order to make it work? Thank you very much! Gyver