whoman Posted February 13, 2020 Share Posted February 13, 2020 Hello everyone! I'm trying to use a small SPI LED screen with my ROC-RK3328-CC. I've scoured all over this website as well as the internet for information on enabling SPI on my ROC-RK3328-CC (libre renegade), and I'm sorry to say after trying so many things, I still cannot get it enabled. I'm currently using this image: Armbian_19.11.7_Renegade_buster_current_5.4.8.img I've added the following 2 lines to /boot/armbienEnv.txt overlays=spi-spidev param_spidev_spi_bus=0 and after reboot, nothing. nothing for dmesg|grep spi and no spidev devices in /dev I've also tried manually changing status to "okay" for fragment@1 and fragment@2 within the dtbo, but still nothing. Did I miss a step in the process of enabling this device tree overlay? I read through the armbiean device tree overlay documentation online and in my overlay folder, but can't seem to figure out what else I might need to do to enable SPI one thing I'm not sure about his how to get detailed u-boot logging like I see so many people post on this forum. is there a file which this gets logged to? Is there a flag I need to set somewhere to enable u-boot logging to a file? Any advice would be much appreciated. Thanks for your time 0 Quote Link to comment Share on other sites More sharing options...
TRS-80 Posted February 13, 2020 Share Posted February 13, 2020 According to this, Renegade is currently Community Support only, so I moved your post to the appropriate forum (P2P). 15 minutes ago, whoman said: one thing I'm not sure about his how to get detailed u-boot logging like I see so many people post on this forum You mean serial output? 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 13, 2020 Author Share Posted February 13, 2020 18 minutes ago, TRS-80 said: According to this, Renegade is currently Community Support only, so I moved your post to the appropriate forum (P2P). You mean serial output? Thank you for moving to the correct place. Is serial output the only way to get the u-boot debug info? Would I need to use a USB TTY device to view this? I assumed the u-boot info was written to some log file. Is that incorrect? What I'm looking for is something that would tell me if the fixup.scr was being executed properly, and any other dt overlay information. At this point I just want to make sure the device tree overlays are actually working Although this is for a different board, this is what I'm talking about (just did a cut and paste from an unrelated thread): Quote U-Boot SPL 2018.11-armbian (Feb 08 2019 - 11:04:44 +0100) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2018.11-armbian (Feb 08 2019 - 11:04:44 +0100) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial Out: serial Err: serial Net: phy interface0 Thanks again for your time 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 13, 2020 Author Share Posted February 13, 2020 Just to be clear, I believe device tree overlays are not working for me, and am wondering how I go about checking. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 13, 2020 Share Posted February 13, 2020 12 hours ago, whoman said: I assumed the u-boot info was written to some log file. Is that incorrect? No ! U-Boot logs are only seen thru Serial Debug ! What " cat /proc/device-tree/spi@ff190000/status " is reporting ? 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 13, 2020 Author Share Posted February 13, 2020 6 hours ago, martinayotte said: No ! U-Boot logs are only seen thru Serial Debug ! What " cat /proc/device-tree/spi@ff190000/status " is reporting ? Thank you for the info... I'll see about ordering a USB TTY debugger when I run that command, there's no output. It just goes straight back to the prompt. I verified that the directory and file do exist: ls -l /proc/device-tree/spi@ff190000/ total 0 -r--r--r-- 1 root root 4 Feb 13 20:19 '#address-cells' -r--r--r-- 1 root root 16 Feb 13 20:19 clock-names -r--r--r-- 1 root root 16 Feb 13 20:19 clocks -r--r--r-- 1 root root 40 Feb 13 20:19 compatible -r--r--r-- 1 root root 6 Feb 13 20:19 dma-names -r--r--r-- 1 root root 16 Feb 13 20:19 dmas -r--r--r-- 1 root root 12 Feb 13 20:19 interrupts -r--r--r-- 1 root root 4 Feb 13 20:19 name -r--r--r-- 1 root root 4 Feb 13 20:19 phandle -r--r--r-- 1 root root 16 Feb 13 20:19 pinctrl-0 -r--r--r-- 1 root root 8 Feb 13 20:19 pinctrl-names -r--r--r-- 1 root root 16 Feb 13 20:19 reg -r--r--r-- 1 root root 4 Feb 13 20:19 '#size-cells' -r--r--r-- 1 root root 9 Feb 13 20:17 status 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 13, 2020 Share Posted February 13, 2020 1 hour ago, whoman said: when I run that command, there's no output. It should, but just at left of the prompt, since doesn't include a newline, it should either "disabled" or "okay" . 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 13, 2020 Author Share Posted February 13, 2020 13 minutes ago, martinayotte said: It should, but just at left of the prompt, since doesn't include a newline, it should either "disabled" or "okay" . just ran it again after reboot and it comes back with disabled user1@renegade:~$ sudo cat /proc/device-tree/spi@ff190000/status disableduser1@renegade:~$ 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 13, 2020 Share Posted February 13, 2020 5 minutes ago, whoman said: disableduser1@renegade:~$ So, somehow, the overlay didn't do its job ! Let see when you will get the USB-TTL dongle ... 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 14, 2020 Author Share Posted February 14, 2020 2 hours ago, martinayotte said: So, somehow, the overlay didn't do its job ! Let see when you will get the USB-TTL dongle ... So I had a spare arduino nano and looked up how to use that as a USB TTL debugger... here's the output (I don't see anything noting the spidev overlay) U-Boot 2017.09-armbian (Jan 07 2020 - 22:21:19 +0100) Model: Firefly ROC-RK3328-CC DRAM: 1022 MiB MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1 Card did not respond to voltage select! mmc_init: -95, time 10 *** Warning - No block device, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Firefly ROC-RK3328-CC misc_init_r boot mode 0. Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2940 bytes read in 14 ms (205.1 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 0 103 bytes read in 11 ms (8.8 KiB/s) 7108882 bytes read in 197 ms (34.4 MiB/s) 20722176 bytes read in 531 ms (37.2 MiB/s) 48336 bytes read in 21 ms (2.2 MiB/s) 2698 bytes read in 21 ms (125 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 04000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7108818 Bytes = 6.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to 3d84c000, end 3df138d2 ... OK reserving fdt memory region: addr=1f00000 size=72000 Loading Device Tree to 000000003d7d7000, end 000000003d84bfff ... OK Starting kernel ... Same result on status... user1@renegade:~$ sudo cat /proc/device-tree/spi@ff190000/status disableduser1@renegade:~$ does this mean the dtbo isn't being loaded? my full /boot/armbienEnv.txt: verbosity=1 overlay_prefix=rockchip rootdev=UUID=69320d26-57b1-49ed-b3d0-c1402e101ae0 rootfstype=ext4 overlays=spi-spidev param_spidev_spi_bus=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u what could I be missing here? 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 14, 2020 Author Share Posted February 14, 2020 So I decided to add uart4 overlay as well (after SPI, I'll be trying to enable UART): verbosity=1 overlay_prefix=rockchip rootdev=UUID=69320d26-57b1-49ed-b3d0-c1402e101ae0 rootfstype=ext4 overlays=spi-spidev uart4 param_spidev_spi_bus=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u and now somehow both are showing up in the debugger however both error out.... Applying kernel provided DT overlay rockchip-spi-spidev.dtbo fdt_overlay_apply(): FDT_ERR_NOTFOUND 384 bytes read in 24 ms (15.6 KiB/s) Applying kernel provided DT overlay rockchip-uart4.dtbo fdt_overlay_apply(): FDT_ERR_BADMAGIC Error applying DT overlays, restoring original DT I then tried placing uart4 before spidev-spi, and the error messages switched, which suggests its not the files themselves... perhaps its the fixup.scr? Applying kernel provided DT overlay rockchip-uart4.dtbo fdt_overlay_apply(): FDT_ERR_NOTFOUND 1266 bytes read in 24 ms (50.8 KiB/s) Applying kernel provided DT overlay rockchip-spi-spidev.dtbo fdt_overlay_apply(): FDT_ERR_BADMAGIC Error applying DT overlays, restoring original DT would it be beneficial to post the contents of the rockchip-fixup.scr? 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 14, 2020 Share Posted February 14, 2020 12 hours ago, whoman said: would it be beneficial to post the contents of the rockchip-fixup.scr? No needs ! But check the presence of this folder "ls -l /boot/dtb/rockchip/overlay/", I suspect it is not there since you got FDT_ERR_NOTFOUND ... 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 14, 2020 Author Share Posted February 14, 2020 9 hours ago, martinayotte said: No needs ! But check the presence of this folder "ls -l /boot/dtb/rockchip/overlay/", I suspect it is not there since you got FDT_ERR_NOTFOUND ... The overlay files are definitely there... /boot/dtb/rockchip/overlay$ ls -l total 36 -rw-r--r-- 1 root root 2455 Jan 4 15:31 README.rockchip-overlays -rw-r--r-- 1 root root 2698 Jan 4 15:31 rockchip-fixup.scr -rw-r--r-- 1 root root 218 Jan 4 15:31 rockchip-i2c7.dtbo -rw-r--r-- 1 root root 218 Jan 4 15:31 rockchip-i2c8.dtbo -rw-r--r-- 1 root root 267 Jan 4 15:31 rockchip-pcie-gen2.dtbo -rw-r--r-- 1 root root 1314 Jan 4 15:31 rockchip-spi-jedec-nor.dtbo -rw-r--r-- 1 root root 1266 Jan 4 15:31 rockchip-spi-spidev.dtbo -rw-r--r-- 1 root root 384 Jan 4 15:31 rockchip-uart4.dtbo -rw-r--r-- 1 root root 491 Jan 4 15:31 rockchip-w1-gpio.dtbo Could it be that the current libre renegade armbian image doesn't have a current (up to date) fixup.scr? Thank you again for your time, I really appreciate it. 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted February 15, 2020 Share Posted February 15, 2020 14 hours ago, whoman said: armbian image doesn't have a current (up to date) fixup.scr? No, since fixup.scr is per family, not per board, and you listing shows the presence of rockchip-fixup.scr. I still don't understand why we are seeing FDT_ERR_NOTFOUND in u-boot logs ... Could you stop u-boot and provide the output of "printenv" ? EDIT: I think I've found a clue about FDT_ERR_NOTFOUND... Most of those overlays were written with RK3399 in perpective, but looking at Main DT using "fdtdump /boot/dtb/rockchip/rk3328-roc-cc.dtb", I don't see any "uart4", as well as "spi1/spi2/spi3", there is only one SPI0, so it is probably why the overlay refuse to be loaded ... You will then need a custom overlay that only try to touch SPI0. 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 15, 2020 Author Share Posted February 15, 2020 Wow thank you so much for your insight! I changed RK3399 to RK3328 I changed ff1c0000 to ff190000 I removed all fragments relating to SPI1/2/3 /dts-v1/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/aliases"; __overlay__ { spi0 = "/spi@ff190000"; }; }; fragment@1 { target = < 0xffffffff >; __overlay__ { #address-cells = < 0x01 >; #size-cells = < 0x00 >; spidev { compatible = "spidev"; status = "disabled"; reg = < 0x00 >; spi-max-frequency = < 0x989680 >; }; }; }; __fixups__ { spi0 = "/fragment@1:target:0"; }; }; And now the device tree appears to be read and applied(?), however I'm getting this error regarding the fixup.scr: Applying kernel provided DT overlay rockchip-spi-spidev.dtbo 2698 bytes read in 21 ms (125 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND Edit: Taking a look at the fixup.scr, it appears the values for SPI0 are hardcoded to ff1c0000. Made the changes, and I tried creating the file using this command: mkimage -A arm -T script -C none -d rockchip-fixup.script rockchip-fixup.scr Image Name: Created: Sat Feb 15 23:09:39 2020 Image Type: ARM Linux Script (uncompressed) Data Size: 2478 Bytes = 2.42 KiB = 0.00 MiB Load Address: 00000000 Entry Point: 00000000 Contents: Image 0: 2470 Bytes = 2.41 KiB = 0.00 MiB and SUCCESS!! $ sudo cat /proc/device-tree/spi@ff190000/status okay Thank you sooooo much for your help with this! I sincerely appreciate you. Now that SPIDEV is enabled on SPI0, I need to determine how to specify the SPI pins for "Reset" and "DataCommand" to Luma.OLED. By default it expects them on BCM 24 and BCM 25, and Luma.OLED allows you to specify which pins to use with the command line argument: you can select other pins and pass a bcm_DC and/or a bcm_RST argument specifying the new BCM pin numbers So I have no idea what the BCM equivilants would be for SPI0 on the RK3328. The only references I have with pin specifications for the libre renegade board are these two: https://roc-rk3328-cc.readthedocs.io/en/latest/_images/hw_expansion_interface.png and this one: I'm using Rock64.GPIO which contains the following Arrays, however I can't figure out how to decypher which BCM pin numbers would translate to the SPI0 RST and DC pins on my ROC-RK3328-CC. # Define GPIO arrays ROCK_valid_channels = [27, 32, 33, 34, 35, 36, 37, 38, 60, 64, 65, 67, 68, 69, 76, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 96, 97, 98, 100, 101, 102, 103, 104] BOARD_to_ROCK = [0, 0, 0, 89, 0, 88, 0, 60, 64, 0, 65, 0, 67, 0, 0, 100, 101, 0, 102, 97, 0, 98, 103, 96, 104, 0, 76, 68, 69, 0, 0, 0, 38, 32, 0, 33, 37, 34, 36, 0, 35, 0, 0, 81, 82, 87, 83, 0, 0, 80, 79, 85, 84, 27, 86, 0, 0, 0, 0, 0, 0, 89, 88] BCM_to_ROCK = [68, 69, 89, 88, 81, 87, 83, 76, 104, 98, 97, 96, 38, 32, 64, 65, 37, 80, 67, 33, 36, 35, 100, 101, 102, 103, 34, 82] Any ideas? 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 18, 2020 Author Share Posted February 18, 2020 I found this pin mapping table which refers to the Rock64, however looking at the GPIO pin numbers, it looks like it very likely is the same board pin numbers for the ROC-RK3328-CC. https://github.com/Leapo/Rock64-R64.GPIO/wiki/GPIO-Modes I will try it out tomorrow afternoon and report back with the results. Thanks everyone. 0 Quote Link to comment Share on other sites More sharing options...
whoman Posted February 24, 2020 Author Share Posted February 24, 2020 I have got this working now... I could only find 2 GPIO pins on the ROC-RK3328-CC that were usable: Labeled "GPIO" - Pin 32 - GPIO0_A0 - Accesible as GPIO 0 Labeled "CLK0" - Pin 22 - GPIO0_A2 - Accesible as GPIO 2 Looking at this table, you can see that BCM 24 and 25 are routed to GPIO 102 and 103 on the ROCK64. https://github.com/Leapo/Rock64-R64.GPIO/wiki/GPIO-Modes So I replaced 102 and 103 with 0 and 2, on the line begining with "BCM_to_ROCK =" I then added 0 and 2 to the line beginning with "ROCK_valid_channels", so that it would pass the sanity checks in the code Now the SPI LED screen is working perfectly. Thank you so much martinayotte! Your help and insight not only helped me get this working, but also helped me learn about device tree overlays and the hardware addressing in the device tree. And because of this new knowledge, I was able to create my own UART1 overlay, and it's working perfectly. 0 Quote Link to comment Share on other sites More sharing options...
richardk Posted March 3, 2021 Share Posted March 3, 2021 (edited) Just to summarize: 1. Use dtc to de-compile the existing rockchip-spi-spidev.dtbo to .dts: dtc -I dtb -O dts /boot/dtb/rockchip/overlay/rockchip-spi-spidev.dtbo -o rockchip-spi-spidev.dts 2. Edit the resulting rockchip-spi-spidev.dts and change instances of ff1c to ff19, and 3399 to 3328 3. (optional?) remove references to spi1, spi2, spi3 4. Compile rockchip-spi-spidev.dts back to dtbo dtc -I dts -O dtb rockchip-spi-spidev.dts -o /boot/dtb/rockchip/overlay/rockchip-spi-spidev.dtbo 5. Extract rockchip-fixup.script from /boot/dtb/rockchip/overlay/rockchip-fixup.scr (just use a text editor, and delete everything before "# overlays fixup script") 6. Edit rockchip-fixup.script and change instances of ff1c to ff19 7. Recompose rockchip-fixup.scr mkimage -A arm -T script -C none -d rockchip-fixup.script /boot/dtb/rockchip/overlay/rockchip-fixup.scr Now, you can use armbian-config to add spidev, and reboot. Edited March 3, 2021 by richardk forgot 3399 1 Quote Link to comment Share on other sites More sharing options...
Amir Hossein Posted November 1, 2022 Share Posted November 1, 2022 (edited) On 3/3/2021 at 10:56 PM, richardk said: Just to summarize: 1. Use dtc to de-compile the existing rockchip-spi-spidev.dtbo to .dts: dtc -I dtb -O dts /boot/dtb/rockchip/overlay/rockchip-spi-spidev.dtbo -o rockchip-spi-spidev.dts 2. Edit the resulting rockchip-spi-spidev.dts and change instances of ff1c to ff19, and 3399 to 3328 3. (optional?) remove references to spi1, spi2, spi3 4. Compile rockchip-spi-spidev.dts back to dtbo dtc -I dts -O dtb rockchip-spi-spidev.dts -o /boot/dtb/rockchip/overlay/rockchip-spi-spidev.dtbo 5. Extract rockchip-fixup.script from /boot/dtb/rockchip/overlay/rockchip-fixup.scr (just use a text editor, and delete everything before "# overlays fixup script") 6. Edit rockchip-fixup.script and change instances of ff1c to ff19 7. Recompose rockchip-fixup.scr mkimage -A arm -T script -C none -d rockchip-fixup.script /boot/dtb/rockchip/overlay/rockchip-fixup.scr Now, you can use armbian-config to add spidev, and reboot. hi everyone I did all the steps mentioned in this post for nanopi Neo3, but the spidev0.0 option is not added in the /dev section Edited November 1, 2022 by Amir Hossein 1 Quote Link to comment Share on other sites More sharing options...
Patrick Pesch Posted August 27, 2023 Share Posted August 27, 2023 Same - Did not work for me on a Libre Renegade rk-3328-cc either. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.