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 ?

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?

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...

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 

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

 

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....

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...?