@lex

Members
  • Content Count

    442
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by @lex

  1. I have some experiments with legacy kernel 4.4 before the BPI updated the kernel source (changes on eMMC and possibly Wifi, my board is too old to check the new features), I don't know if it has been improved or not. Recently, the mainline stable kernel 4.20 has reached a very stable condition and you can even run KODI on A64, thanks to jernejsk's work. I think the problem is on the new eMMC version. I can't help on this since i don't have this hw revision. Tip: try to build Armbian without enabling eMMC and/or Wifi and see what happens. Grab the complete boot log, i think there are others here with the new hw revision that can help.
  2. This weekend I was revising and testing the OV5640 for some A64 boards. To enable the Camera (OV5640) on NanoPi A64 for the mainline kernel you have to update the following: * DT * GPIO-I2C Here is the excerpt : Kernel config: CONFIG_I2C_GPIO=m CONFIG_VIDEO_OV5640=m CONFIG_VIDEO_SUN6I_CSI=m
  3. Hmm. maybe you mean CPU version. A64 is the old one and R18 is the new one, they are essentially the same. Maybe you mean eMMC version , the new one has a newer eMMC version and you should run with a newer Kernel version that handles this new eMMC.
  4. Maybe when you install the games it updates the libGl or libEGL. I think this would happen to all distro but you could try to freeze (somehow) the libs on Armbian which has symlink to libmali. As a suggestion, you could install symlinks and find the libs and its symlink. Try on the first install: symlinks /lib/aarch64-linux-gnu Take notes and then do it again after reboot.
  5. That's the reason. It updates to new libEGL and breaks the symlink to libmali. If for some reason the new lib is installed you have to manually re-create the symlinks, or just don't update.
  6. Another interesting thing, i have been running my kernel without any patch related to the issue and have not seen any problem on my NanoPi A64. Although i don't usually run for a long time so the issue could manifest in time. I had a comment about this on linux-sunxi list a long time ago, maybe i was just lucky. I will have a look at your PR.
  7. Do you have an RTC backup battery attached to your Pine64?
  8. I see now. Then "reset" is not working properly, i suppose. stmac did not reset. If someone can check, do a cold boot, do a reboot and do a reboot again and check eth0.
  9. @froezus I don't see your u-boot patched , it is the only ATF that should be patched?
  10. I changed the timeout value from 100 ms (stmac had 10 ms and now has 100 ms) to 200 ms to see if could help,i get stmac crashes with this value. If i issue a sudo reboot from this session (100 ms default) again the OPI One Plus reboot normally. Changing u-boot version ethernet works on reboot but not hdmi. I also patched only ATF and not u-boot and i get random results, sometimes it works some times not. I am not sure u-boot must be patched.
  11. I would like to mention that I have reported a similar issue to @froezus , although i am using a different u-boot (in fact it's his u-boot) and latest kernel to experiment with. It seems u-boot and minor .config changes plays an important role in this case. If you can grab some dmesg output, check if you have something similar to this: dmesg|grep ethernet [ 0.879244] dwmac-sun8i 5020000.ethernet: EMAC reset timeout [ 0.879786] dwmac-sun8i: probe of 5020000.ethernet failed with error -14 [ 4.388248] platform 5020000.ethernet eth0: device MAC address c6:70:90:27:15:44 [ 4.388263] platform 5020000.ethernet eth0: Could not attach to PHY [ 4.394739] platform 5020000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) This usually occurs on the first reboot, subsequent reboots restore ethernet connection. I have tested his previous patch and latest patch he submitted and for some reason, i got different behavior on reboot.
  12. "chip found is not an target chip" usually means you have issues with i2c (twi) talking to the sensor. Looks like a hardware issue to me, if possible try with another sensor or get a second board with a new sensor.
  13. Just an update to i2c and spi. The pin node definition i2c0 and i2c1 are reversed. It works. (5.0.1) So i think it is safe to assume i2c and spi are working, just need someone with better experience with the spi LCD to find the right DT configuration for the mainline 5.0.y . Hope this help. i2cdetect -l i2c-3 i2c DesignWare HDMI I2C adapter i2c-1 i2c mv64xxx_i2c adapter I2C adapter i2c-2 i2c mv64xxx_i2c adapter I2C adapter i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- 3d -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --
  14. Using this code i got an output but similar to the previous one. https://github.com/rm-hull/spidev-test ./spidev_test -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@....�..................�. PS: the TX data: uint8_t default_tx[] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x40, 0x00, 0x00, 0x00, 0x00, 0x95, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF0, 0x0D, };
  15. Can you share your DT changes? Did you use the new dma? O used this code: https://github.com/torvalds/linux/blob/master/tools/spi/spidev_test.c
  16. Yes, I guess this is a confirmation SPI is not working yet. I used the -v to see some output (the spidev_test did not return anything). I had some hope that TX would be the data sent and RX would be the receiving data which is the same.
  17. @jernej FYI, i just did a simple test on /dev/spidev.0.0 with a loop, not sure what should be the result, but here it is: ./spidev_test -v -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................| RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................|
  18. That seems to be the case here. Unfortunately, I have to wait for this support. Thanks anyway.
  19. Sure, but sorry, no progress yet to test your code, I got stuck with the error below and i could not figure out where the mistake is. The message is obvious, but the same setup works with others sbc with 4.18, 4.19 and 4.20. [ 3.455164] sun50i-h6-pinctrl 300b000.pinctrl: pin PC5 already requested by 5010000.spi; cannot claim for 300b000.pinctrl:69 [ 3.444948] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 3.454515] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 3.454940] fbtft_of_value: buswidth = 8 [ 3.454947] fbtft_of_value: debug = 0 [ 3.454950] fbtft_of_value: rotate = 90 [ 3.454953] fbtft_of_value: fps = 60 [ 3.454955] fbtft_of_value: txbuflen = 16384 [ 3.476347] fb_ili9341 spi0.0: gpio_request_one('cs-gpios'=69) failed with -22 [ 3.483740] fb_ili9341: probe of spi0.0 failed with error -22 [ 4.091824] sun4i-drm display-engine: fb0: DRM emulated frame buffer device dma: dma-controller@3002000 { compatible = "allwinner,sun50i-h6-dma"; reg = <0x03002000 0x1000>; interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_DMA>, <&ccu CLK_MBUS_DMA>; clock-names = "bus", "mbus"; dma-channels = <16>; dma-requests = <46>; resets = <&ccu RST_BUS_DMA>; #dma-cells = <1>; }; pio: pinctrl@300b000 { . . spi0_pins: spi0 { pins = "PC0", "PC2", "PC3", "PC5"; function = "spi0"; }; }; spi0: spi@5010000 { compatible = "allwinner,sun8i-h3-spi"; reg = <0x05010000 0x1000>; interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>; clock-names = "ahb", "mod"; dmas = <&dma 23>, <&dma 23>; dma-names = "rx", "tx"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; resets = <&ccu RST_BUS_SPI0>; status = "disabled"; num-cs = <1>; #address-cells = <1>; #size-cells = <0>; }; &pio { spi0_cs_pins: spi0_cs_pins { pins = "PC5", "PH3"; function = "gpio_out"; }; }; &spi0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-0 = <&spi0_pins &spi0_cs_pins>; cs-gpios = <&pio 2 5 GPIO_ACTIVE_HIGH>, <&pio 7 3 GPIO_ACTIVE_HIGH>; num-cs = <2>; pitft: pitft@0{ compatible = "ilitek,ili9341"; reg = <0>; status = "okay"; spi-max-frequency = <50000000>; rotate = <90>; fps = <60>; bgr = <1>; buswidth = <8>; txbuflen = <16384>; dc-gpios = <&pio 2 9 GPIO_ACTIVE_HIGH>; /* PC9 */ reset-gpios = <&pio 2 8 GPIO_ACTIVE_HIGH>; /* PC8 */ led-gpios = <&pio 2 7 GPIO_ACTIVE_LOW>; /* PC7 */ cs-gpios = <&pio 2 5 GPIO_ACTIVE_HIGH>; /* PC5 */ <== kernel complain debug = <0x0>; }; };
  20. Okay, I promise i will try to learn that. Anyway, Your dma code seems to work for the SPI0 although the device is not connected yet and need some tests. [ 3.983705] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 3.990224] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 3.990921] fbtft_of_value: buswidth = 8 [ 3.990929] fbtft_of_value: debug = 0 [ 3.990932] fbtft_of_value: rotate = 90 [ 3.990934] fbtft_of_value: fps = 60 [ 3.990936] fbtft_of_value: txbuflen = 16384 [ 4.273841] graphics fb0: fb_ili9341 frame buffer, 320x240, 150 KiB video memory, 16 KiB buffer memory, fps=62, spi0.0 at 50 MHz [ 4.276796] sun4i-drm display-engine: fb1: DRM emulated frame buffer device
  21. Err... Just don't know how to do that... In a proper way I mean.
  22. The opi3-h6.dts i pointed to already have all the nodes. HDMI works like a charm. Those who will try need to compile the kernel with Wifi and BT enabled. I synced the regulators with H64 but that does not fix the reboot issue. I just noticed the power ON/OFF button works, maybe the H64 does not have this button? Do you have any suggestion about i2c? I will use your dma code and see if i get SPI0 to work.
  23. Nice. BTW Do you have mali working on your kernel?
  24. These are the changes from H64 and OpiOne+ @@ -161,6 +155,7 @@ regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-name = "vcc-ac200"; + regulator-enable-ramp-delay = <100000>; }; reg_aldo3: aldo3 { @@ -219,7 +214,7 @@ reg_dcdca: dcdca { regulator-always-on; regulator-min-microvolt = <810000>; - regulator-max-microvolt = <1160000>; + regulator-max-microvolt = <1080000>; regulator-name = "vdd-cpu"; };
  25. Forgot to print the dma used: dma: dma-controller@3002000 { compatible = "allwinner,sun50i-a64-dma"; reg = <0x03002000 0x1000>; interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_DMA>; dma-channels = <8>; dma-requests = <27>; resets = <&ccu RST_BUS_DMA>; #dma-cells = <1>; };