[Libre-soc-dev] Tercel SPI controller setup requirements

[Timothy Pearson]

Figured this should be documented publicly, especially as it relates to the latest kan-ban update, so cleaned up a bit and posted to the list here.

> On Sun, Apr 10, 2022 at 6:18 PM lkcl <luke.leighton at gmail.com> wrote:
>
> sorry, it all wasn't working, and interfering with the firmware memcpy
> i'm doing,
>
> aw gawd, there's actually nothing "wrong" with the memcpy... it's
> just that at byte-at-a-time it's literally only capabie of doing 1024
> bytes every every 4 seconds in XIP mode!
>
> urrrr... that means i have to use SPI Flash "proper" read stuff.
>
> is Tercel compatible with this?
> https://github.com/antonblanchard/microwatt/blob/master/litedram/gen-src/sdram_init/main.c#L109
>
> or, put another way: is the litex qspi code compatible with Tercel?
>
> l.

Nope, completely different peripherals.  The basic principle is the same, but the registers / access patterns are different.

And yes, of course when you bring a controller up in maximum compatibility mode it's going to be snail-in-treacle slow.  One of the first things everyone does when they're building a boot ROM from SPI is configure at least the SPI clock speed as fast as possible to get a better data rate.  This configuration sequence should be among the first instructions in the boot ROM for maximum effect, perhaps only second to core setup such as endian switching.

Here's what we do as early as possible during Kestrel startup:

https://gitlab.raptorengineering.com/kestrel-collaboration/kestrel-litex/litex/-/blob/master/litex/soc/software/bios/boot.c#L575

A couple of other notes on the general process...

When you build a SPI Flash bootrom image (i.e. the bootblock bit) you typically know at least the general class of SPI device being targeted.  The most bang for the buck comes from 1.) increasing clocks and 2.) enabling read merging if the device supports it, so at bootblock compile time you basically know if it's safe to put a handful of instructions or so right at the start of the bootblock to turn those features on (note the commands just blast out configuration data and don't try to read or compute anything).  That means you're only needing to load a few dozen bytes at most from the start of the bootblock in the slowest SPI mode, and if you really do want to connect some horrible ancient SPI device without read merging you just need to flash a different bootblock to it vs. creating a new SoC. 

Then *after* you've blasted out the couple of register updates that allow 10x or 100x read speed increases, you do the full detection and configuration routine like this:

https://gitlab.raptorengineering.com/kestrel-collaboration/kestrel-firmware/bare-metal-firmware/-/blob/master/main.c#L2328

That's where you start really pulling in various timings and switch things over to QSPI mode, running from XIP compatibility mode initially but increasing transfer rates all through the configuration process until finally you're running at the maximum speed the hardware supports.

As of right now ls2 is only doing the stage 1 optimizations, the bootloader should really be modified to detect the Flash device and enable QSPI along with the other speed optimizations available to the N25Q parts.  This would cut the kernel load times significantly, perhaps even as much as an order of magnitude.