Question 6.1. in this section says: Examine the later parts of the capture data. Do they look like SPI? Why or why not?
The walk through did not answer this question. I see non-SPI traffic in my logical analyzer but I don’t understand why that would occur. Is that just random noise on the line when the chip is not in use or is something else sharing and using the same bus?
Thanks for asking - i’ll look at clarifying that in the lab and make sure i add that next time i’m revising the walkthrough video.
There’s two things that happen later on in the SPI capture.
At first, we’re loading the bootloader using simple fixed 32-bit memory-mapped accesses at low speed. When it’s time to load the kernel, we want that to happen faster, so the SoC will do a faster bulk read from the SPI flash chip. I don’t recall how fast, but i believe it reads at 25Mbps, which is faster than our logic analyzer can capture reliably. The result is partial data - sometimes we see nothing, sometimes it looks like random 1s and 0s, and sometimes (usually when we capture at a integer fraction of the actual data rate) we see strange patterns that don’t appear to make sense
Finally, the kernel loads and the system boots. Here, there’s a dedicated SPI controller driver, that turns the SPI flash chip into QSPI mode - quad spi. This uses DI, DO, WP and HOLD all as data lines, all at higher speed, to get 4x the throughput Pulseview does have a qspi decoder now, but again, we would need to sample tons of data to analyze that fully.
-joe
Thanks, that makes a lot of sense.