martinayotte Posted February 20, 2019 Posted February 20, 2019 6 minutes ago, Nao said: I did all the things mentioned here and checked the boot logs.... then nothing appeared... So, it reach login prompt, you've logged in an still don't see the /dev/spidev0.0 ? What shows up doing "grep SPIDEV /boot/config-*" ? It should show : CONFIG_SPI_SPIDEV=m Which kernel are you using ? 1
Jeffer Posted February 21, 2019 Author Posted February 21, 2019 11 hours ago, martinayotte said: So, it reach login prompt, you've logged in an still don't see the /dev/spidev0.0 ? What shows up doing "grep SPIDEV /boot/config-*" ? It should show : well, I meant nothing appeared, so the screen is remaining black after the boot I can check /var/log/bootstrap.log with other LINUX machine but can this show the latest log? for the kernel version, "uname -r" returns "4.4.162-rk3399" Should I upgrade this kernel?
martinayotte Posted February 21, 2019 Posted February 21, 2019 11 hours ago, Nao said: well, I meant nothing appeared, so the screen is remaining black after the boot I can check /var/log/bootstrap.log with other LINUX machine but can this show the latest log? Well, as said before, use the USB-TTL Serial, when reaching the login prompt, log into it, then do "dmesg" to see complete boot log. 11 hours ago, Nao said: Should I upgrade this kernel? Of course you can try the latest mainline, which is the one I use on my T4, but maybe something else will be missing, depending of your needs...
Jeffer Posted February 21, 2019 Author Posted February 21, 2019 2 hours ago, martinayotte said: Well, as said before, use the USB-TTL Serial, when reaching the login prompt, log into it, then do "dmesg" to see complete boot log. I mean, when I tried as I usually do with USB-TTL, unfortunately the screen is just black, shows nothing ( implying no data coming via UART-TTL? ) If this makes no sense, sorry for that but this is what I got so far... 2 hours ago, martinayotte said: Of course you can try the latest mainline, which is the one I use on my T4, but maybe something else will be missing, depending of your needs... Now Im using this legacy kernel just because it is distributed here https://www.armbian.com/nanopi-m4/ If there are some possibilities that SPI can work by updating the latest mainline, I'm happy to do that but I would like you to tell me how, I couldn't find the method
martinayotte Posted February 21, 2019 Posted February 21, 2019 4 minutes ago, Nao said: I mean, when I tried as I usually do with USB-TTL, unfortunately the screen is just black, shows nothing ( implying no data coming via UART-TTL? ) You must have wired it incorrectly by swapping TX/RX ... Even if you have done something wrong in DTB, you should see the u-boot logs followed by kernel logs with "console=serial" in /boot/armbianEnv.txt 5 minutes ago, Nao said: latest mainline, I'm happy to do that but I would like you to tell me how, I couldn't find the method There is Mainline nightly build here : https://dl.armbian.com/nanopim4/Debian_stretch_dev_nightly.7z
Jeffer Posted February 22, 2019 Author Posted February 22, 2019 19 hours ago, martinayotte said: You must have wired it incorrectly by swapping TX/RX ... Even if you have done something wrong in DTB, you should see the u-boot logs followed by kernel logs with "console=serial" in /boot/armbianEnv.txt well I checked the connection so many times so it should be correct Also, with a default DTB I can log in via UART with the following command % sudo screen -L /dev/tty.usbserial-FTADURC2 1500000 I attached the pic of my USB-TTL on nano pi so you can check it 19 hours ago, martinayotte said: There is Mainline nightly build here : https://dl.armbian.com/nanopim4/Debian_stretch_dev_nightly.7z I will try with this kernel EDIT: good news. with the nightly, nano pi booted after editing the DTB /dev/spidev0.0 appeared so I tested with it but nothing happened, I remembered that spi0 is for other use I'll try with the other spi, not spi@ff1d0000 ->well, with spi@ff1e0000 spidev0.0 appeared...and this doesn't work I think something was wrong so I'll try again -> whichever spi@ff1***** I edited, /dev/spidev0.0 always appeared I edited rk3399-nanopi4-rev01.dtb but this isn't the DTB that I should fix? by accident I destroyed that file and I rebooted it but it was fine and the results were the same....
Jeffer Posted February 26, 2019 Author Posted February 26, 2019 I succeeded to boot spi1.0 somehow... I edited device tree by following your way and I got the result below Quote $ dmesg | grep spi [ 3.032463] rockchip-spi ff1d0000.spi: Failed to request TX DMA channel [ 3.032502] rockchip-spi ff1d0000.spi: Failed to request RX DMA channel [ 7.093333] /spi@ff1d0000/spidev: buggy DT: spidev listed directly in DT [ 7.093360] WARNING: CPU: 5 PID: 450 at drivers/spi/spidev.c:730 spidev_probe+0xfc/0x1d8 [spidev] [ 7.093361] Modules linked in: spidev(+) rockchip_io_domain pcie_rockchip_host(+) nvmem_rockchip_efuse input_polldev rockchip_saradc zram ip_tables x_tables ipv6 btrfs xor zstd_decompress zstd_compress xxhash zlib_deflate raid6_pq realtek phy_rockchip_typec phy_rockchip_pcie rtc_rk808 dwmac_rk stmmac_platform stmmac [ 7.093394] pc : spidev_probe+0xfc/0x1d8 [spidev] [ 7.093398] lr : spidev_probe+0xfc/0x1d8 [spidev] [ 7.093447] spidev_probe+0xfc/0x1d8 [spidev] [ 7.093456] spi_drv_probe+0x7c/0xd8 [ 7.093479] __spi_register_driver+0x58/0x60 [ 7.093484] spidev_init+0x9c/0x1000 [spidev] and /dev/spidev1.0 appeared (by default, this was spidev0.0 but after I added spi1 = "/spi@ff1d0000" to aliases in dts, the spidev1.0 appeared) I felt so happy this time and tested that spidev1.0 function with spidev_test.c and I got following result again... Quote spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) I'm using spidev1.0 this time but this result again... what can I do now...?
Recommended Posts