2 2
whoman

RK3328 - how to enable SPI

Recommended Posts

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Just to be clear, I believe device tree overlays are not working for me, and am wondering how I go about checking.

 

Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
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" .

Share this post


Link to post
Share on other sites
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:~$

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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?

 

 

Share this post


Link to post
Share on other sites
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  ...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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:c3bad9354eae0c3df65f607d9a56c2a80a6f465f

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?

 

 

 

 

 

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
2 2