Jump to content

martinayotte

Members
  • Posts

    3892
  • Joined

  • Last visited

Everything posted by martinayotte

  1. As I said, formatting is completely not needed since "etcher" will overwrite using partition scheme provided by the image.
  2. PA13 is SPI1_CS ... Are you sure the SPI1 is disabled ? What "cat /proc/device-tree/soc/spi@1c69000/status" is reporting ?
  3. It seems a trouble accessing a specific GPIO, not related to SPI, but message with %d is not meanful. To get it more meanful, you need to fix it there : https://github.com/nRF24/RF24/blob/master/utility/SPIDEV/gpio.cpp#L48 It should probably be instead : throw GPIOException("can't access /sys/class/gpio/gpio%d/direction GPIO pin. check access rights", port); You can also check if the previous "export" worked by looking at "ls -l /sys/class/gpio/" to seen if the specific GPIO been exported. Maybe the GPIO is already in use, you can verify that by doing "cat /sys/kernel/debug/gpio" ...
  4. From my knowledge/understanding, it only mean that kernel has been compiled with CONFIG_SPI_SLAVE enabled, but no hardware is attached to it since neither drivers/spi/spi-sun4i.c and drivers/spi/spi-sun6i.c provide such functionalities. EDIT: you have probably seen that this /sys/class/spi_slave folder is empty ...
  5. What "cat /sys/kernel/debug/gpio" is reporting ? Which kernel are you using ? What "uname -a" shows ? BTW, "GPIO.cleanup()" is usually called when program exit, but at the beginning ...
  6. Even easier than that : decompile DTB currently present on you board, edit the resulting DTS by changing "status" node of "spi-gpio" to "okay" instead of "disabled", then recompile DTS into DTB.
  7. Check "dmesg | grep tty" because, for example, if UART1 is not enabled, then UART2 will be assigned to /dev/ttyS1 not S2 ...
  8. No, it is too complex task ... I don't understand what you mean ...
  9. As I said, kernel driver for AllWinner SoC doesn't support "slave" mode. What do you mean by testing baud rate ? If you wish to measure/verify the clock, you can take a oscilloscope...
  10. Don't do that, it can burn your H5 UART, RS232 are using inverted level of +/- 9V to 12V !!! Right ! Not only CP2102, but there are others, such CH340. Seeing your footer, in the meantime, you can use your OPiZero since it has UART1 on header.
  11. Unfortunately, although the H5 hardware is capable, Linux kernel driver doesn't support slave mode.
  12. Beware that TX output of OPiLite2 is 3.3V while your Arduino RX expect 5V, so it is maybe the reason why you don't see any output ... Better purchase a 3.3V compatible USB-TTL dongle.
  13. Most SoC are not "slave capable" but only "master" ...
  14. All those are working fine. Wifi ? Yes ! Others are not tested ... Maybe soon, since 5.6.0 is now at RC6 ...
  15. That is a MUST if you wish to help figured out why your PBP doesn't boot. BTW, no one here got an Armbian image working with the LCD display yet ! We still have to figure out why, but it will take time ...
  16. You don't need to format any SDCard before writing an image ... The image is providing the formatting ...
  17. Most probably because you don't have "avahi-daemon" installed or its configs in /etc/avahi/avahi-daemon.conf doesn't have "publish-workstation" set to "yes" ...
  18. I suggest that you get equipped with a USB-TTL Serial dongle and provide the boot log to see what is happening during the boot phase ...
  19. Most of them are working as long as they are 2.7V and above. Frequency is not really an issue since in DT it is usually set 40MHz and could be lowered manually by editing DTS. I've used Winbond ones on both my OPiZeros and OPiPC2. So, I suggest Winbond one, but maybe also GigaDevice.
  20. Ok ! I've figured it out ! The fixup scripts /boot/dtb/overlay/sun7i-a20-fixup.scr, /boot/dtb/overlay/sun5i-a13-fixup.scr and /boot/dtb/overlay/sun4i-a10-fixup.scr are all using "soc@1c00000" node instead of plain "soc" node, while the script /boot/dtb/overlay/sun8i-h3-fixup.scr is already using the good node naming. The reason is because in the old days of 4.x.y, the node was named "soc@1c00000" while in 5.x.y it is the shorter version. I will fix that in Armbian patches later ... In the meantime, you can do backup of /boot/dtb/overlay/sun7i-a20-fixup.scr, copy it also as /root/sun7i-a20-fixup.cmd, edit it, remove the binary header until "# overlays fixup script" header, search all "soc@1c00000" and replace by plain "soc", save the file, and finally convert it again in script file using "mkimage -C none -A arm -T script -d /root/sun7i-a20-fixup.cmd /boot/dtb/overlay/sun7i-a20-fixup.scr" EDIT: Commit done ! https://github.com/armbian/build/commit/ca24fd20e48ff6e004279b0cb14dca746231e648
  21. What kind of chip is used on that USB-TTL ? Did you tried to plug it as loopback wire to see if echos are doing the same or becomes clear ?
  22. Those errors in your boot log seems to be the culprit : libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND Maybe something missing in Banana-M1 DTB that prevent resolving SPIDEV overlay. I will look into it when I get chance...
  23. In fact, I will try to make it almost compatible with original Armbian /boot/boot.cmd so that I could benefit of the overlay loading scheme ...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines