This post is a continuation of part 1 @ link. It shows the solution to part 1's issue then starts to scrub the QSPI device-tree to ensure everything looks okay.
Solved Part 1
After more debug I found the problem.
I needed to remove:
is-dual is used for this configuration (diagram from page 664 of the TRM):
However, I'm using the single slave configuration show below.
After finding this I decided to scrub through the remaining device-tree SPI nodes.
The rest of the post presents the scrub.
Set Up for this Post
The env variables used in this post are created in setup_env.sh.
This script is part of a set of scripts to manage a build for a Zynq UltraScale+ MPSoC board available at link.
In this case changes to the DT file are made to ./project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi
From page 663 of ZU+ TRM
Scrub the Device Tree
Get the Actual Device Tree Used
Output the compiled DTB to the console:
Ensure Each Field is Needed
Output (reformated a little):
File that's used to create the DTB.
- compatible : Should be "xlnx,zynqmp-qspi-1.0".
Dump of file:
Code @ drivers/spi/spi-zynqmp-gqspi.c does this:
GQSPI_DEFAULT_NUM_CS is 1:
We only have one CS and the default does the right thing so remove.
has-io-mode, is-dual, is-stacked are not used.
Set Up The Com
Run a Test
Note: If you Control-C any of the insmod lines, you don't need to rmmod.
Tests looked good.
Find just dm-pre-reloc
Same result: its not used by itself.
What is u-boot,dm-pre-reloc?
u-boot,dm-pre-reloc is used by U-Boot not the Linux kernel.
It tells U-Boot that this device is a "pre-relocation device."
If U-Boot calls dm_scan_fdt_dev() before relocation, only devices marked with this string will be bound.
A bound device is an instance of a driver connected to a port or peripheral, i.e. memory has been reserved for the device and you can then use the device to work with the port or peripheral.
U-Boot typically starts running in ROM space then relocates it self to RAM. u-boot,dm-pre-reloc would indicate that the device is needed pre-reallocation.
Is it needed?
It may be needed since we may run U-Boot out of the SPI at some point. It is also not doing any harm where it is for our build because Linux doesn't read it. Leave it.
What is the 4 for and who references this: interrupt-parent = <0x4>;
There's a great write up here on what the 0x4 means. Short story, you should look for a device that lists "phandle = <0x4>" thats the interrupt parent. In our case:
What do all of these values map to: reg = <0x0 0xff0f0000 0x0 0x1000 0x0 0xc0000000 0x0 0x8000000>?
The info on reg, #address-cells and #size-cells came from here.
The parent node is needed to interpret this.
The spi controller is at 0x00000000ff0f0000 and is 0x0000000000001000 long. They is also an address range at: 0x00000000c0000000 that is 0000000080000000 long defined.
The first range is used to access the QSPI Controller's registers: see link.
It is read here in drivers/spi/spi-zynqmp-gqspi.c:
A printk in devm_ioremap_resource() shows:
The second address and length does not appear to be used in Linux or in U-Boot. Should it be removed?
It does look like a range that may be used in U-Boot . 0xc0000000 looks like PAGE_OFFSET on a 32-bit machine and 0x80000000 looks like a 2 GB range. This would put the highest address outside of a 32-address space.
Like u-boot,dm-pre-reloc it doesn't _seem_ to harm anything so leaving it in for now.