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.